ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Taylor <saurs...@yahoo.com>
Subject Re: Client calling retired process?
Date Mon, 13 Oct 2008 17:55:17 GMT
Thanks, Matthieu.  Some background:
we're running ODE 1.2 on Websphere 6.1, with Oracle 10g as the process store.
This scenario consistently fails in the manner I described, but it seems only for certain
So, for example, if i have the following:
deployed in my environment, the scenario would be that something causes ProcessA-20 to hang
- at which point it goes into recovery mode and spawns an ode job to retry.  From this point
on, new requests to (not just) ProcessA get routed to the now-retired ProcessA-19, but also
new requests to ProcessB get routed to (now-retired) ProcessB-20!  The weird thing is, ProcessC-22
is apparently unaffected.  It still gets calls legitimately routed to its latest versioned
deployment, ProcessC-22.
I do not know if this happens under other scenarios unrelated to recovery.  I think I just
do not have enough data points yet to say.

----- Original Message ----
From: Matthieu Riou <matthieu@offthelip.org>
To: user@ode.apache.org
Sent: Monday, October 13, 2008 12:33:18 PM
Subject: Re: Client calling retired process?

On Mon, Oct 13, 2008 at 8:17 AM, Chris Taylor <saursoor@yahoo.com> wrote:

> Thanks, Alexis, but i'm no closer to fully understanding why this occurs.
> It happens periodically now almost everyday with different deployed
> processes.  Although I don't understand it, I have done some research into
> the behaviour.  Here's a scenario:
> we'll deploy ProcessA-19, then retire it with ProcessA-20 deployment.  At
> some point it, or another, process will fail and attempt to go into recovery
> mode (excuse me if I state this incorrectly),  at this point ODE will create
> a scheduled job in an attempt to retry the service later.
> Here's where it gets screwy.  From then on, all new calls to ProcessA will
> not route to ProcessA-20, but ode will attempt to route them to ProcessA-19,
> which is of course retired. Ode does not recover from this.  It seems the
> only way to compensate is to redeploy ProcessA as ProcessA-21.  New requests
> will then route correctly.
> Any idea here?

I'll have to ask a few more questions to narrow it down and make sure I
understand correctly:

  * Does the exact same scenario sometimes works and sometimes doesn't?
  * Is it always happening in relation with recovery and retry or did you
see it happen in other situations as well?
  * Which version of ODE are you using? Have you tried with a recent 1.X


> ----- Original Message ----
> From: Alexis Midon <midon@intalio.com>
> To: user@ode.apache.org
> Sent: Wednesday, October 8, 2008 7:26:54 PM
> Subject: Re: Client calling retired process?
> Hi Chris,
> No new executions can be started on a retired process, but running
> instances
> can still finish their job. [1]
> I'm not really familiar with this part of the code, but after looking at
> it,
> it seems to me that the deployment of a new version is not atomic. Meaning
> that a process could be flagged as retired while the creation of a new
> instance is in progress, hence you're exception.
> does it make sense regarding your scenario? is it possible that the process
> gets retired while messages are coming in?
> [1] further details here:
> http://ode.apache.org/user-guide.html#UserGuide-Versioning
> On Wed, Oct 8, 2008 at 11:37 AM, Chris Taylor <saursoor@yahoo.com> wrote:
> > Okay, I've a deployment (called GetCodes) bundle that includes 5
> > processes.  4 of the processes make calls to the fifth (it's an
> abstraction
> > layer of process business logic).  When I deploy this "GetCodes" bundle
> > using the DeploymentService utility, I can see an incremented deployment
> > (say, GetCodes-40) alongside previous iterations.
> >
> > Occasionally, I'll have a client making soap calls to one of the
> processes
> > under this logical bundle that will fail with the following error:
> >
> > InvalidProcessException: Process is retired.
> >
> > In the logs, it's clear that ODE is directing this client call to
> > GetCodes-39 - though the client isn't explicitly attempting to call a
> > specific version (is that even possible?).  Any clue why some clients
> > periodically - erroneously - are directed by ODE to a retired process
> > version?
> >
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message