ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matthieu.r...@gmail.com>
Subject Re: Invalid response state for mex ASYNCH
Date Wed, 02 May 2007 14:13:07 GMT
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:


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!


On 5/2/07, Michael Kammholz <mka@arlanis.com> 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
> eM@il:  michael.kammholz@arlanis.com
> Amtsgericht Potsdam: HRB 19134 P
> Steuer Nr.: 046 100 01292
> Vorstand: Christian Metzger

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