Hi Michael, I've been looking into this even more deeply. Without being able to reproduce the problem, it's kind of hard to track down. The thing is that the reply method in BpelRuntimeContextImpl only gets called when the process needs to produce a reply to the process client, not when the process calls a service and gets a response for it. The problem Jan reported seemed to happen in invocationResponse2, which is really executed when the response from a service invoked by the engine gets processed. So I would think that your problem is in the same area of the code, which is more consistent with the exception being thrown. The "invalid response state for mex ASYNC" can only get thrown *before* the reply method is executed.
Would you be kind enough to try to reproduce this problem and send a full log of the execution? Just set the ODE category in log4j to debug like this: log4j.category.org.apache.ode=DEBUG With this I should be able to see messages that comes in and out, which SQL statements get executed (or not) and hopefully find the answer to your problem. A full stacktrace will probably help as well. I recommend zipping the log as it's going to be big. And then you can either send it to the list or create a Jira issue and attach it. Thanks for your time and patience! Matthieu On 5/2/07, Michael Kammholz <[EMAIL PROTECTED]> wrote:
We tried to trace this issue down a bit and found out that when deploying the process with the flag "in-memory" (deploy.xml) the error does NOT occour (Tested with a build from 04.16). As mentioned from Jan Loewe the problem seems to be in the method BpelRuntimeContextImpl.reply(...) or rather in the DAO handling in that area. In this method the state is set correctly to Status.RESPONSE for the MyRoleMessageExchangeImpl instance on line 528 and MessageExchangeDAO on line 535 (shouldn't this happen inherent on line 528 ?). But this only affects the objects in memory, not in the database. Then on line 540 the pmex object is loaded where the status is reloaded from database and reset to ASYNC for any object with this MEX-ID so the object m now has the wrong status in the switch statement after this. This does not happen when process is deployed with the in-memory flag. Hope that helps to review the right section to solve this problem. Beside that, with a build from today the aforementioned stack overflow still happens: java.lang.StackOverflowError at org.apache.axis2.client.Options.getTransportOut(Options.java:331) Any idea why that happens? Best regards, Michael -- Michael Kammholz Arlanis Software AG Kurfürstenstr. 15 14467 Potsdam http://www.arlanis.com Phone: +49 331 27911-29 Fax: +49 331 27911-1 [EMAIL PROTECTED]: [EMAIL PROTECTED] Amtsgericht Potsdam: HRB 19134 P Steuer Nr.: 046 100 01292 Vorstand: Christian Metzger
