You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Michael Kammholz <mk...@arlanis.com> on 2007/05/02 11:17:38 UTC
Re: Invalid response state for mex ASYNCH
Hi there,
I also have this error here with a ode built today. Additionally there's a
stack overflow at:
java.lang.StackOverflowError at
org.apache.axis2.client.Options.getTransportOut(Options.java:331)
The stack overflow doesn't seem to belong to the asynch-error, because an
older ode-version has the same error without the stack overflow.
The invoked webservice works standalone and the bpel-script contains a
simple receive, invoke, and reply.
So if there's a solution yet or if I can provide useful additional
information to solve the problem, please let me know.
Best,
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
Re: Invalid response state for mex ASYNCH
Posted by Alex Boisvert <bo...@intalio.com>.
On 5/2/07, Michael Kammholz <mk...@arlanis.com> wrote:
>
> Hi Alex,
>
> Unfortunately there's still a problem in this version. Now there's no
> stackoverflow but a OutOfMemoryError when trying to invoke a webservice.
> I've attached the ODE output in debug mode.
I couldn't reproduce the OutOfMemoryError but I fixed an additional bug I
had introduced yesterday in r534585. Can you see if it fixes your issue?
thanks,
alex
Re: Invalid response state for mex ASYNCH
Posted by Vipul Sabhaya <vi...@hotmail.com>.
I am seeing this as well. I was getting the Invalid Response State for Mex
ASYNC Error, but then i set the process to run in-memory. I don't see that
error now, but i now see the OutOfMemory Error.
>From: "Michael Kammholz" <mk...@arlanis.com>
>Reply-To: ode-user@incubator.apache.org
>To: ode-user@incubator.apache.org
>Subject: Re: Invalid response state for mex ASYNCH
>Date: Wed, 02 May 2007 19:22:17 +0200
>MIME-Version: 1.0
>Received: from mail.apache.org ([140.211.11.2]) by
>bay0-mc4-f23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 2
>May 2007 10:25:07 -0700
>Received: (qmail 7717 invoked by uid 500); 2 May 2007 17:25:13 -0000
>Received: (qmail 7708 invoked by uid 99); 2 May 2007 17:25:13 -0000
>Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
>by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2007 10:25:13 -0700
>Received: neutral (herse.apache.org: local policy)
>Received: from [212.227.126.183] (HELO moutng.kundenserver.de)
>(212.227.126.183) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May
>2007 10:24:57 -0700
>Received: from [217.83.105.54] (helo=marvin.kleineshotel.dyndns.org)by
>mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis),id
>0MKwh2-1HjIYz3SvW-0004J3; Wed, 02 May 2007 19:24:33 +0200
>X-Message-Info:
>LsUYwwHHNt33LQyNQTlXjyhElDlguglyGvKnnOZCumQLcZd5yNaE2Khn6bZJa373
>Mailing-List: contact ode-user-help@incubator.apache.org; run by ezmlm
>Precedence: bulk
>List-Help: <ma...@incubator.apache.org>
>List-Unsubscribe: <ma...@incubator.apache.org>
>List-Post: <ma...@incubator.apache.org>
>List-Id: <ode-user.incubator.apache.org>
>Delivered-To: mailing list ode-user@incubator.apache.org
>X-ASF-Spam-Status: No, hits=-0.0 required=10.0tests=SPF_HELO_PASS
>X-Spam-Check-By: apache.org
>Organization: Arlanis Software AG
>References: <BA...@phx.gbl>
><op...@marvin.kleineshotel.dyndns.org>
><op...@marvin.kleineshotel.dyndns.org>
><55...@mail.gmail.com>
>User-Agent: Opera Mail/9.20 (Win32)
>X-Provags-ID: V01U2FsdGVkX19nl2sbwQ0quN8G/BYBzq2CSiIqCImqx6NJTF5
>5/j+wF0mblbdImF9cGpZ6FfenOiFFyJkP+wEMVko6kNtHkwIsy
>lR52oiKa/eNM2bifWDkdbYftIRsCb64
>X-Virus-Checked: Checked by ClamAV on apache.org
>Return-Path:
>ode-user-return-493-vipulsabhaya=hotmail.com@incubator.apache.org
>X-OriginalArrivalTime: 02 May 2007 17:25:07.0796 (UTC)
>FILETIME=[D46E1140:01C78CDE]
>
>Hi Alex,
>
>Unfortunately there's still a problem in this version. Now there's no
>stackoverflow but a OutOfMemoryError when trying to invoke a webservice.
>I've attached the ODE output in debug mode.
>
>Best,
>Michael
>
>Am 02.05.2007, 16:04 Uhr, schrieb Alex Boisvert <bo...@intalio.com>:
>
>>On 5/2/07, Michael Kammholz <mk...@arlanis.com> wrote:
>>>
>>>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)
>>
>>
>>Ooops! I was too aggressive on the refactoring yesterday. Fixed in
>>trunk
>>(r534469).
>>
>>alex
>
>
>
>--
>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
><< Log1.txt >>
_________________________________________________________________
Dont quit your job Take Classes Online and Earn your Degree in 1 year.
Start Today!
http://www.classesusa.com/clickcount.cfm?id=866146&goto=http%3A%2F%2Fwww.classesusa.com%2Ffeaturedschools%2Fonlinedegreesmp%2Fform-dyn1.html%3Fsplovr%3D866144
Re: Invalid response state for mex ASYNCH
Posted by Michael Kammholz <mk...@arlanis.com>.
Hi Alex,
Unfortunately there's still a problem in this version. Now there's no
stackoverflow but a OutOfMemoryError when trying to invoke a webservice.
I've attached the ODE output in debug mode.
Best,
Michael
Am 02.05.2007, 16:04 Uhr, schrieb Alex Boisvert <bo...@intalio.com>:
> On 5/2/07, Michael Kammholz <mk...@arlanis.com> wrote:
>>
>> 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)
>
>
> Ooops! I was too aggressive on the refactoring yesterday. Fixed in
> trunk
> (r534469).
>
> alex
--
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
Re: Invalid response state for mex ASYNCH
Posted by Alex Boisvert <bo...@intalio.com>.
On 5/2/07, Michael Kammholz <mk...@arlanis.com> wrote:
>
> 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)
Ooops! I was too aggressive on the refactoring yesterday. Fixed in trunk
(r534469).
alex
Re: Invalid response state for mex ASYNCH
Posted by Matthieu Riou <ma...@gmail.com>.
Hi Michael,
That's great! Thanks for all your help in the diagnosis. This reminds me
that even if we have pretty decent testing for the engine, we're lacking
tests for the messaging layer. One more thing to work on....
Cheers,
Matthieu
On 5/3/07, Michael Kammholz <mk...@arlanis.com> wrote:
>
> Hi Alex, hi Matthieu,
>
> good news - both issues are fixed in a todays build. No OutOfMemoryError
> occours and the webservice invocation returns without errors.
> Thanks for the fast response.
>
> Best,
> 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
>
Re: Invalid response state for mex ASYNCH
Posted by Michael Kammholz <mk...@arlanis.com>.
Hi Alex, hi Matthieu,
good news - both issues are fixed in a todays build. No OutOfMemoryError
occours and the webservice invocation returns without errors.
Thanks for the fast response.
Best,
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
Re: Invalid response state for mex ASYNCH
Posted by Matthieu Riou <ma...@gmail.com>.
Michael,
Thanks a lot for debugging this through! I think I've found the problem. The
message exchange was being reused between transactions. As it's backed by a
persistent object, changes in the second transaction were just ignored. This
monkey business was working with Hibernate but doesn't with OpenJPA. So I've
changed it to reload the message exchange properly, it should now work.
If you can give it a try and tell me how it goes, that would be super!
Thanks,
Matthieu
On 5/2/07, Michael Kammholz <mk...@arlanis.com> wrote:
>
> Hi Matthieu,
>
> here some - hopefully - new findings:
>
> First - you're totally right, the code indicated in my last mail is only
> called at the end of the BPEL-process, so it has nothing to do with this
> error.
> The problem is indeed between setting the state to RESPONSE in
> MessageExchangeImpl.setResponse() and getting this value in
> BpelRuntimeContextImpl.invocationResponse2(), because when asking for the
> MessageExchangeDAO in invocationResponse2() the EntityManager cannot find
> the current Object where _status is set to RESPONSE and creates a new
> Instance where _status is ASYNC. Here is the stack trace when the state is
> reset to ASYNC:
>
> Thread [pool-4-thread-2] (Suspended (modification of field _status in
> MessageExchangeDAOImpl))
> MessageExchangeDAOImpl.pcClearFields() line: not available
> MessageExchangeDAOImpl.pcNewInstance(StateManager, Object,
> boolean) line:
> not available
> PCRegistry.newInstance(Class, StateManager, Object, boolean) line:
> 118
> StateManagerImpl.initialize(Class, PCState) line: 247
> JDBCStoreManager.initializeState(OpenJPAStateManager, PCState,
> JDBCFetchConfiguration, ConnectionInfo) line: 327
> JDBCStoreManager.initialize(OpenJPAStateManager, PCState,
> FetchConfiguration, Object) line: 252
>
> ROPStoreManager(DelegatingStoreManager).initialize(OpenJPAStateManager,
> PCState, FetchConfiguration, Object) line: 108
> ROPStoreManager.initialize(OpenJPAStateManager, PCState,
> FetchConfiguration, Object) line: 54
> FinalizingBrokerImpl(BrokerImpl).initialize(StateManagerImpl,
> boolean,
> FetchConfiguration, Object) line: 873
> FinalizingBrokerImpl(BrokerImpl).find(Object, FetchConfiguration,
> BitSet,
> Object, int, FindCallbacks) line: 831
> FinalizingBrokerImpl(BrokerImpl).find(Object, boolean,
> FindCallbacks)
> line: 748
> DelegatingBroker.find(Object, boolean, FindCallbacks) line: 169
> EntityManagerImpl.find(Class<T>, Object) line: 346
> BPELDAOConnectionImpl.getMessageExchange(String) line: 155
> BpelRuntimeContextImpl.invocationResponse2(String,
> InvokeResponseChannel)
> line: 953
> BpelRuntimeContextImpl.access$000(BpelRuntimeContextImpl, String,
> InvokeResponseChannel) line: 89
> BpelRuntimeContextImpl$4.run() line: 939
> GeneratedMethodAccessor19.invoke(Object, Object[]) line: not
> available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
> Method.invoke(Object, Object...) line: 585
> JacobVPU$JacobThreadImpl.run() line: 451
> JacobVPU.execute() line: 139
> BpelRuntimeContextImpl.execute() line: 817
> BpelProcess.handleWorkEvent(Map<String,Object>) line: 310
> BpelEngineImpl.onScheduledJob(Scheduler$JobInfo) line: 311
> BpelServerImpl.onScheduledJob(Scheduler$JobInfo) line: 384
> QuartzSchedulerImpl.doExecute(Scheduler$JobInfo) line: 351
> QuartzSchedulerImpl.execute(JobExecutionContext) line: 367
> JobImpl.execute(JobExecutionContext) line: 32
> JTAJobRunShell(JobRunShell).run() line: 203
> ThreadPoolExecutor$Worker.runTask(Runnable) line: 650
> ThreadPoolExecutor$Worker.run() line: 675
> Thread.run() line: 595
>
> So maybe there is a transaction not committed after setting state to
> RESPONSE or anything else to trigger the persistance layer?
>
> Hope that helps a bit.
> Also I've attachted the console output of ODE in debug mode for further
> information.
>
> Best,
> 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
>
Re: Invalid response state for mex ASYNCH
Posted by Michael Kammholz <mk...@arlanis.com>.
Hi Matthieu,
here some - hopefully - new findings:
First - you're totally right, the code indicated in my last mail is only
called at the end of the BPEL-process, so it has nothing to do with this
error.
The problem is indeed between setting the state to RESPONSE in
MessageExchangeImpl.setResponse() and getting this value in
BpelRuntimeContextImpl.invocationResponse2(), because when asking for the
MessageExchangeDAO in invocationResponse2() the EntityManager cannot find
the current Object where _status is set to RESPONSE and creates a new
Instance where _status is ASYNC. Here is the stack trace when the state is
reset to ASYNC:
Thread [pool-4-thread-2] (Suspended (modification of field _status in
MessageExchangeDAOImpl))
MessageExchangeDAOImpl.pcClearFields() line: not available
MessageExchangeDAOImpl.pcNewInstance(StateManager, Object, boolean) line:
not available
PCRegistry.newInstance(Class, StateManager, Object, boolean) line: 118
StateManagerImpl.initialize(Class, PCState) line: 247
JDBCStoreManager.initializeState(OpenJPAStateManager, PCState,
JDBCFetchConfiguration, ConnectionInfo) line: 327
JDBCStoreManager.initialize(OpenJPAStateManager, PCState,
FetchConfiguration, Object) line: 252
ROPStoreManager(DelegatingStoreManager).initialize(OpenJPAStateManager,
PCState, FetchConfiguration, Object) line: 108
ROPStoreManager.initialize(OpenJPAStateManager, PCState,
FetchConfiguration, Object) line: 54
FinalizingBrokerImpl(BrokerImpl).initialize(StateManagerImpl, boolean,
FetchConfiguration, Object) line: 873
FinalizingBrokerImpl(BrokerImpl).find(Object, FetchConfiguration, BitSet,
Object, int, FindCallbacks) line: 831
FinalizingBrokerImpl(BrokerImpl).find(Object, boolean, FindCallbacks)
line: 748
DelegatingBroker.find(Object, boolean, FindCallbacks) line: 169
EntityManagerImpl.find(Class<T>, Object) line: 346
BPELDAOConnectionImpl.getMessageExchange(String) line: 155
BpelRuntimeContextImpl.invocationResponse2(String, InvokeResponseChannel)
line: 953
BpelRuntimeContextImpl.access$000(BpelRuntimeContextImpl, String,
InvokeResponseChannel) line: 89
BpelRuntimeContextImpl$4.run() line: 939
GeneratedMethodAccessor19.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 585
JacobVPU$JacobThreadImpl.run() line: 451
JacobVPU.execute() line: 139
BpelRuntimeContextImpl.execute() line: 817
BpelProcess.handleWorkEvent(Map<String,Object>) line: 310
BpelEngineImpl.onScheduledJob(Scheduler$JobInfo) line: 311
BpelServerImpl.onScheduledJob(Scheduler$JobInfo) line: 384
QuartzSchedulerImpl.doExecute(Scheduler$JobInfo) line: 351
QuartzSchedulerImpl.execute(JobExecutionContext) line: 367
JobImpl.execute(JobExecutionContext) line: 32
JTAJobRunShell(JobRunShell).run() line: 203
ThreadPoolExecutor$Worker.runTask(Runnable) line: 650
ThreadPoolExecutor$Worker.run() line: 675
Thread.run() line: 595
So maybe there is a transaction not committed after setting state to
RESPONSE or anything else to trigger the persistance layer?
Hope that helps a bit.
Also I've attachted the console output of ODE in debug mode for further
information.
Best,
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
Re: Invalid response state for mex ASYNCH
Posted by Matthieu Riou <ma...@gmail.com>.
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 <mk...@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
>
Re: Invalid response state for mex ASYNCH
Posted by Michael Kammholz <mk...@arlanis.com>.
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