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? ________________________________ 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
