On Tue, Nov 25, 2008 at 2:01 PM, Chris Taylor <[EMAIL PROTECTED]> wrote:
> Brilliant! Thanks, Alex. > > Incidentally, in analyzing this issue it would seem that the process store > was holding multiple "Active" versions of the same process (so, multiple > PIDs of the same Type in the STORE_PROCESS were Active at the same time). > > I wonder if this development environment, wherein we are using the > DeploymentService to deploy Deployment Units (and thus versioned deployment > directories), combined with a couple different deployments of the ODE > runtime engine was causing these "logically" retired processes to hang > around as Active. > > Going out on a limb here, but does it make sense during times of recovery > that the engine might get confused about which process Type to route to if > there were multiple Active Process IDs of it at the same time? > Yeah, in that case the result is undefined. There's basically no way for the engine to guess which one is the real destination. Matthieu > > > > > > ________________________________ > From: Alex Boisvert <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, November 25, 2008 2:50:47 PM > Subject: Re: Client calling retired process? > > On Tue, Nov 25, 2008 at 12:46 PM, Chris Taylor <[EMAIL PROTECTED]> wrote: > > > Oh, jeez. Forget that last one, I obviously wasn't thinking about it > > enough before I posted it. We have deployed a couple of different > versions > > of the ODE runtime engine, and Websphere stomps on the previous each time > we > > do, so we lose the actual /processes/deployment folder for previous, > retired > > process versions in that scenario. > > > > Still, perhaps a good argument for an external, configurable processes > > folder? > > > I believe Ode uses the "ode-axis2.working.dir" property in > ode-axis2.properties: > > e.g. > ode-axis2.working.dir=${org.apache.ode.configDir}/../ > > alex > > > > >
