FATAL in BpelRuntimeContextImpl

[Arkadiusz Burdach]

Hi.

I'm using ode 1.2RC1 on servicemix and with Oracle DB and I've got some
fatal error:

FATAL | pool-4-thread-3 | BpelRuntimeContextImpl   |
.engine.BpelRuntimeContextImpl 1147 | Engine requested response while
the message exchange hqejbhcnphr3fj1lkxovvt was in the state RESPONSE

ERROR | pool-4-thread-3 | JacobVPU                 |
b.vpu.JacobVPU$JacobThreadImpl  463 | Method "onRequestRcvd" in class
"org.apache.ode.bpel.runtime.PICK$WAITING$2" threw an unexpected exception.
org.apache.ode.bpel.iapi.BpelEngineException: Engine requested response
while the message exchange hqejbhcnphr3fj1lkxovvt was in the state RESPONSE
 >---at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.getMyRequest(BpelRuntimeContextImpl.java:1148)
 >---at org.apache.ode.bpel.runtime.PICK.initVariable(PICK.java:160)
 >---at org.apache.ode.bpel.runtime.PICK.access$400(PICK.java:51)
 >---at
org.apache.ode.bpel.runtime.PICK$WAITING$2.onRequestRcvd(PICK.java:258)
 >---at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
 >---at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 >---at java.lang.reflect.Method.invoke(Method.java:585)
 >---at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
 >---at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
 >---at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:833)
 >---at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.matcherEvent(BpelRuntimeContextImpl.java:1344)
 >---at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:408)
 >---at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:326)

I want to implement very simple scenario: Two processes communicate each
other. Main process initialize corellation set by property in input
message, then invoke operation in Partner process. This response
immediately, do something with input data and copy result with
corellating property to next message. Last one is sended to Main process
(receive with the same corellation set but not initializing) which take
it and end by responsing result.

I've send paraller about 10 messages and got 10 positive answers, but
when I've tried to send more messages, I've got this exception and after
that, on any request I've got:

java.lang.IllegalStateException: Exchange not found

and in smx logs:

(...)
DEBUG - BpelRuntimeContextImpl         - MatcherEvent handling: nothing
to do, no matching message in DB

and process is in state of last receive.

I've attached diagram in intalio and maven's project which creates
service assembly.

Regards, Arek

[Alex Boisvert-3]

Hi Arkadiusz,

Thanks for the bug report.  Sounds like there's a concurrency issue in the
JBI IL.   I won't have time to look into this in the very near future, so if
you have the guts to look deeper in the code now, feel free to investigate
and ask questions if you need help.

cheers,
alex


On Tue, Jul 15, 2008 at 5:28 AM, Arkadiusz Burdach <abr@...> wrote:

> Hi.
>
> I'm using ode 1.2RC1 on servicemix and with Oracle DB and I've got some
> fatal error:
>
> FATAL | pool-4-thread-3 | BpelRuntimeContextImpl   |
> .engine.BpelRuntimeContextImpl 1147 | Engine requested response while the
> message exchange hqejbhcnphr3fj1lkxovvt was in the state RESPONSE
>
> ERROR | pool-4-thread-3 | JacobVPU                 |
> b.vpu.JacobVPU$JacobThreadImpl  463 | Method "onRequestRcvd" in class
> "org.apache.ode.bpel.runtime.PICK$WAITING$2" threw an unexpected exception.
> org.apache.ode.bpel.iapi.BpelEngineException: Engine requested response
> while the message exchange hqejbhcnphr3fj1lkxovvt was in the state RESPONSE
> >---at
> org.apache.ode.bpel.engine.BpelRuntimeContextImpl.getMyRequest(BpelRuntimeContextImpl.java:1148)
> >---at org.apache.ode.bpel.runtime.PICK.initVariable(PICK.java:160)
> >---at org.apache.ode.bpel.runtime.PICK.access$400(PICK.java:51)
> >---at
> org.apache.ode.bpel.runtime.PICK$WAITING$2.onRequestRcvd(PICK.java:258)
> >---at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
> >---at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >---at java.lang.reflect.Method.invoke(Method.java:585)
> >---at
> org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
> >---at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
> >---at
> org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:833)
> >---at
> org.apache.ode.bpel.engine.BpelRuntimeContextImpl.matcherEvent(BpelRuntimeContextImpl.java:1344)
> >---at
> org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:408)
> >---at
> org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:326)
>
> I want to implement very simple scenario: Two processes communicate each
> other. Main process initialize corellation set by property in input message,
> then invoke operation in Partner process. This response immediately, do
> something with input data and copy result with corellating property to next
> message. Last one is sended to Main process (receive with the same
> corellation set but not initializing) which take it and end by responsing
> result.
>
> I've send paraller about 10 messages and got 10 positive answers, but when
> I've tried to send more messages, I've got this exception and after that, on
> any request I've got:
>
> java.lang.IllegalStateException: Exchange not found
>
> and in smx logs:
>
> (...)
> DEBUG - BpelRuntimeContextImpl         - MatcherEvent handling: nothing to
> do, no matching message in DB
>
> and process is in state of last receive.
>
> I've attached diagram in intalio and maven's project which creates service
> assembly.
>
> Regards, Arek
>

[Arkadiusz Burdach]

Alex Boisvert wrote:

> Hi Arkadiusz,
>
> Thanks for the bug report.  Sounds like there's a concurrency issue in the
> JBI IL.   I won't have time to look into this in the very near future, so if
> you have the guts to look deeper in the code now, feel free to investigate
> and ask questions if you need help.
>
> cheers,
> alex
>  

Yep. I'm still looking on it. Do you have some easy or not easy ways to
use debuging in JBI IL?

cheers,
Arek

[Alex Boisvert-3]

On Thu, Jul 17, 2008 at 1:41 AM, Arkadiusz Burdach <abr@...> wrote:

> Alex Boisvert wrote:
>
>> Hi Arkadiusz,
>>
>> Thanks for the bug report.  Sounds like there's a concurrency issue in the
>> JBI IL.   I won't have time to look into this in the very near future, so
>> if
>> you have the guts to look deeper in the code now, feel free to investigate
>> and ask questions if you need help.
>>
>> cheers,
>> alex
>>
>>
> Yep. I'm still looking on it. Do you have some easy or not easy ways to use
> debuging in JBI IL?

I don't have any secret tricks... I mostly use lots of Log4J debug messages
and writing test cases to isolate parts of the IL.  Sometimes I drop into a
debugger/profiler for more obscure issues.

alex

[Arkadiusz Burdach]

Alex Boisvert wrote:
>>> Thanks for the bug report.  Sounds like there's a concurrency issue in the
>>> JBI IL.   I won't have time to look into this in the very near future, so
>>> if
>>> you have the guts to look deeper in the code now, feel free to investigate
>>> and ask questions if you need help.
>>>      
Hi.

I think, that I knew what is the reason of this bug. I found out that
after some processes, some MessageExchange is stored in some Correlators
in case that, this ME is useless. There is invoked release() method on
this ME but in this method nothing is happened. In the fact, this ME
doesn't exist in their Correlator in exchanges list. I've tried to do
quick fix by adding:

       if (_process != null)
            _process.removeMEXFromAllCorrelators(this);

in dao-jpa/src/main/java/org/apache/ode/dao/jpa/MessageExchangeDAOImpl.java

in vi dao-jpa/src/main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java:

    public void removeMEXFromAllCorrelators(MessageExchangeDAO mex) {
        for (CorrelatorDAO c : _correlators) {
            ((CorrelatorDAOImpl)c).removeMEX(mex);
        }
    }


and in dao-jpa/src/main/java/org/apache/ode/dao/jpa/CorrelatorDAOImpl.java:

    public void removeMEX(MessageExchangeDAO mex) {
        _exchanges.remove(mex);
    }


but this double-used MessageExchange is still in some other Correlator.

How it is possible? Maybe somebody can give me some advices, how to
remove some ME from all possible Correlators? And it will be fine, if
architect of runtime module will tell me, if I'm trying to break some
concept.

Cheers, Arek

[Matthieu Riou-5]

On Mon, Jul 21, 2008 at 3:16 AM, Arkadiusz Burdach <abr@...> wrote:

> Alex Boisvert wrote:
>
>> Thanks for the bug report.  Sounds like there's a concurrency issue in the
>>>> JBI IL.   I won't have time to look into this in the very near future,
>>>> so
>>>> if
>>>> you have the guts to look deeper in the code now, feel free to
>>>> investigate
>>>> and ask questions if you need help.
>>>>
>>>>
>>> Hi.
>
> I think, that I knew what is the reason of this bug. I found out that after
> some processes, some MessageExchange is stored in some Correlators in case
> that, this ME is useless.

I'm not completely sure I'm following but maybe if I give you more detail
about how that work, you'll be able to track down the problem a little
better. First, it's normal that you have some MEX attached to a correlator.
Sometimes messages tend to arrive before the receive that's supposed to pick
them up is ready (the process is still executing some earlier step). In the
case we just save the MEX on the correlator (calling enqueueMessage). Later
on, when the receive finally gets executed, it checks the correlator to see
if it has a message that could match. So having MEXs associated with your
correlator is normal.

Second, the same type of interactions seem to work with the web service IL.
So I wouldn't look too deeply into the runtime, as it's most probably a bug
in the JBI IL or an interaction specific to it.

Now from your exception, it seems that when the receive tries to pickup a
message that has been saved earlier (because at that time the receive wasn't
ready), the MEX isn't in the right state. It should be either in the REQUEST
or ASYNC state but definitely not in the RESPONSE state as the MEX is just
being picked so there's no way a response can be ready at that point. So
what I would look for is where the MEX state gets changed to the RESPONSE
state and why, keeping the scenario I've just described in mind (message
gets delivered, receive is not there, message gets saved, receive is finally
ready and picks it up).

Hope this helps,

Matthieu

> There is invoked release() method on this ME but in this method nothing is
> happened. In the fact, this ME doesn't exist in their Correlator in
> exchanges list. I've tried to do quick fix by adding:
>
>      if (_process != null)
>           _process.removeMEXFromAllCorrelators(this);
>
> in dao-jpa/src/main/java/org/apache/ode/dao/jpa/MessageExchangeDAOImpl.java
>
> in vi dao-jpa/src/main/java/org/apache/ode/dao/jpa/ProcessDAOImpl.java:
>
>   public void removeMEXFromAllCorrelators(MessageExchangeDAO mex) {
>       for (CorrelatorDAO c : _correlators) {
>           ((CorrelatorDAOImpl)c).removeMEX(mex);
>       }
>   }
>
>
> and in dao-jpa/src/main/java/org/apache/ode/dao/jpa/CorrelatorDAOImpl.java:
>
>   public void removeMEX(MessageExchangeDAO mex) {
>       _exchanges.remove(mex);
>   }
>
>
> but this double-used MessageExchange is still in some other Correlator.
>
> How it is possible? Maybe somebody can give me some advices, how to remove
> some ME from all possible Correlators? And it will be fine, if architect of
> runtime module will tell me, if I'm trying to break some concept.
>
> Cheers, Arek
>

[Arkadiusz Burdach]

Matthieu Riou wrote:

> I'm not completely sure I'm following but maybe if I give you more detail
> about how that work, you'll be able to track down the problem a little
> better. First, it's normal that you have some MEX attached to a correlator.
> Sometimes messages tend to arrive before the receive that's supposed to pick
> them up is ready (the process is still executing some earlier step). In the
> case we just save the MEX on the correlator (calling enqueueMessage). Later
> on, when the receive finally gets executed, it checks the correlator to see
> if it has a message that could match. So having MEXs associated with your
> correlator is normal.
>
> Second, the same type of interactions seem to work with the web service IL.
> So I wouldn't look too deeply into the runtime, as it's most probably a bug
> in the JBI IL or an interaction specific to it.
>  

I've checked, if the same problem is in web IL, and it also is, so it
looks like a problem in runtime. It shouldn't work so if process ends
and MEX is useless, it shouldn't be removed? What will be done if
property of correlation set will be initialized by some value e.g. some
id in incoming message and after process'es end, after while somebody
send message with the same id? I think, that process should check, to
which point message exchage will be useful and if it already out of use,
should be removed from correlator, so matching will work fine. Am I right?

> Now from your exception, it seems that when the receive tries to pickup a
> message that has been saved earlier (because at that time the receive wasn't
> ready), the MEX isn't in the right state. It should be either in the REQUEST
> or ASYNC state but definitely not in the RESPONSE state as the MEX is just
> being picked so there's no way a response can be ready at that point. So
> what I would look for is where the MEX state gets changed to the RESPONSE
> state and why, keeping the scenario I've just described in mind (message
> gets delivered, receive is not there, message gets saved, receive is finally
> ready and picks it up).
>
> Hope this helps,
>
> Matthieu
>  

[Matthieu Riou-5]

On Tue, Jul 22, 2008 at 9:03 AM, Arkadiusz Burdach <abr@...> wrote:

> Matthieu Riou wrote:
>
>> I'm not completely sure I'm following but maybe if I give you more detail
>> about how that work, you'll be able to track down the problem a little
>> better. First, it's normal that you have some MEX attached to a
>> correlator.
>> Sometimes messages tend to arrive before the receive that's supposed to
>> pick
>> them up is ready (the process is still executing some earlier step). In
>> the
>> case we just save the MEX on the correlator (calling enqueueMessage).
>> Later
>> on, when the receive finally gets executed, it checks the correlator to
>> see
>> if it has a message that could match. So having MEXs associated with your
>> correlator is normal.
>>
>> Second, the same type of interactions seem to work with the web service
>> IL.
>> So I wouldn't look too deeply into the runtime, as it's most probably a
>> bug
>> in the JBI IL or an interaction specific to it.
>>
>>
> I've checked, if the same problem is in web IL, and it also is, so it looks
> like a problem in runtime. It shouldn't work so if process ends and MEX is
> useless, it shouldn't be removed? What will be done if property of
> correlation set will be initialized by some value e.g. some id in incoming
> message and after process'es end, after while somebody send message with the
> same id? I think, that process should check, to which point message exchage
> will be useful and if it already out of use, should be removed from
> correlator, so matching will work fine. Am I right?
>

I've just tried it and it works for me. I've actually added your test case
to our test suite as I thought it was a good example of two sync MEXs
happening at the same time. You can try it for yourself:

http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X/bpel-test/src/test/resources/bpel/2.0/TestConcurrentSyncMex/

Now that I see your exact scenario, I remember having fixed something in the
OutstandingRequestManager some time ago. Can you check if ODE 1.2 fixes the
problem for you?

Thanks,
Matthieu

>
>  Now from your exception, it seems that when the receive tries to pickup a
>> message that has been saved earlier (because at that time the receive
>> wasn't
>> ready), the MEX isn't in the right state. It should be either in the
>> REQUEST
>> or ASYNC state but definitely not in the RESPONSE state as the MEX is just
>> being picked so there's no way a response can be ready at that point. So
>> what I would look for is where the MEX state gets changed to the RESPONSE
>> state and why, keeping the scenario I've just described in mind (message
>> gets delivered, receive is not there, message gets saved, receive is
>> finally
>> ready and picks it up).
>>
>> Hope this helps,
>>
>> Matthieu
>>
>>
>

[Arkadiusz Burdach]

Matthieu Riou wrote:
> I've just tried it and it works for me. I've actually added your test case
> to our test suite as I thought it was a good example of two sync MEXs
> happening at the same time. You can try it for yourself:
>
> http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X/bpel-test/src/test/resources/bpel/2.0/TestConcurrentSyncMex/
>  
How can I run this test? If I do buildr test, I have a great deal of
errors. Mainly java.lang.OutOfMemoryError: Java heap space.

$ echo $JAVA_OPTS
-Xms1024m -Xmx2048m

So I tried to comment out failing tests:
axis2-war/src/test/java/org/apache/ode/axis2/management/DeploymentTest.java
axis2-war/src/test/java/org/apache/ode/axis2/management/InstanceManagementTest.java

but I have bigger problem with:
axis2-war/src/test/java/org/apache/ode/axis2/Axis2TestBase.java
I can't get it work at all. I have:

    [junit] DbError
    [junit] org.apache.ode.bpel.iapi.ContextException: DbError
    [junit]     at
org.apache.ode.store.ProcessStoreImpl.exec(ProcessStoreImpl.java:544)
    [junit]     at
org.apache.ode.store.ProcessStoreImpl.loadAll(ProcessStoreImpl.java:456)
    [junit]     at org.apache.ode.axis2.ODEServer.init(ODEServer.java:194)
    [junit]     at
org.apache.ode.axis2.Axis2TestBase$ODEAxis2Server.start(Axis2TestBase.java:70)
    [junit]     at
org.apache.ode.axis2.Axis2TestBase.startServer(Axis2TestBase.java:36)
    [junit]     at
org.apache.ode.axis2.Axis2TestBase.setUp(Axis2TestBase.java:45)
    [junit] Caused by: java.util.concurrent.ExecutionException:
java.lang.OutOfMemoryError: Java heap space
    [junit]     at
java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:205)
    [junit]     at java.util.concurrent.FutureTask.get(FutureTask.java:80)
    [junit]     at
org.apache.ode.store.ProcessStoreImpl.exec(ProcessStoreImpl.java:542)
    [junit] Caused by: java.lang.OutOfMemoryError: Java heap space
    [junit]     at
org.apache.xmlbeans.impl.store.CharUtil.allocate(CharUtil.java:397)
    [junit]     at
org.apache.xmlbeans.impl.store.CharUtil.saveChars(CharUtil.java:441)
    [junit]     at
org.apache.xmlbeans.impl.store.CharUtil.saveChars(CharUtil.java:419)
    [junit]     at
org.apache.xmlbeans.impl.store.Cur$CurLoadContext.comment(Cur.java:3090)
    [junit]     at
org.apache.xmlbeans.impl.store.Locale$SaxHandler.comment(Locale.java:3289)
    [junit]     at
org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportComment(Piccolo.java:1190)
    [junit]     at
org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:4394)
    [junit]     at
org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290)
    [junit]     at
org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400)
    [junit]     at
org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714)
    [junit]     at
org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3439)
    [junit]     at
org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1270)
    [junit]     at
org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1257)
    [junit]     at
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
    [junit]     at
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:252)
    [junit]     at
org.apache.ode.bpel.dd.DeployDocument$Factory.parse(DeployDocument.java:62)
    [junit]     at
org.apache.ode.store.DeploymentUnitDir.getDeploymentDescriptor(DeploymentUnitDir.java:219)
    [junit]     at
org.apache.ode.store.DeploymentUnitDir.scan(DeploymentUnitDir.java:141)
    [junit]     at
org.apache.ode.store.ProcessStoreImpl.load(ProcessStoreImpl.java:608)
    [junit]     at
org.apache.ode.store.ProcessStoreImpl$6.call(ProcessStoreImpl.java:461)
    [junit]     at
org.apache.ode.store.ProcessStoreImpl$Callable.call(ProcessStoreImpl.java:701)
    [junit]     at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
    [junit]     at java.util.concurrent.FutureTask.run(FutureTask.java:123)
    [junit]     at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
    [junit]     at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
    [junit]     at java.lang.Thread.run(Thread.java:595)

Is there is some solution for my problems? Maybe there is possibility to
run only bpel-test without other?
I'm completely noob in rake/buildr.

> Now that I see your exact scenario, I remember having fixed something in the
> OutstandingRequestManager some time ago. Can you check if ODE 1.2 fixes the
> problem for you?
>  
I've checked. There is the same sitution. For replay this scenario, must
be invoked about 10-15 processes paraller. Maybe this is the point, why
it doesn't work on your machine but on yours does. I'm still trying to
fix this bug but I will be thankful for any help.

Cheers, Arek

[Matthieu Riou-5]

On Thu, Jul 24, 2008 at 5:56 AM, Arkadiusz Burdach <abr@...> wrote:

> Matthieu Riou wrote:
>
>> I've just tried it and it works for me. I've actually added your test case
>> to our test suite as I thought it was a good example of two sync MEXs
>> happening at the same time. You can try it for yourself:
>>
>>
>> http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X/bpel-test/src/test/resources/bpel/2.0/TestConcurrentSyncMex/
>>
>>
> How can I run this test? If I do buildr test, I have a great deal of
> errors. Mainly java.lang.OutOfMemoryError: Java heap space.
>
> $ echo $JAVA_OPTS
> -Xms1024m -Xmx2048m
>
> So I tried to comment out failing tests:
> axis2-war/src/test/java/org/apache/ode/axis2/management/DeploymentTest.java
>
> axis2-war/src/test/java/org/apache/ode/axis2/management/InstanceManagementTest.java
>
> but I have bigger problem with:
> axis2-war/src/test/java/org/apache/ode/axis2/Axis2TestBase.java
> I can't get it work at all. I have:
>
>   [junit] DbError
>   [junit] org.apache.ode.bpel.iapi.ContextException: DbError
>   [junit]     at
> org.apache.ode.store.ProcessStoreImpl.exec(ProcessStoreImpl.java:544)
>   [junit]     at
> org.apache.ode.store.ProcessStoreImpl.loadAll(ProcessStoreImpl.java:456)
>   [junit]     at org.apache.ode.axis2.ODEServer.init(ODEServer.java:194)
>   [junit]     at
> org.apache.ode.axis2.Axis2TestBase$ODEAxis2Server.start(Axis2TestBase.java:70)
>   [junit]     at
> org.apache.ode.axis2.Axis2TestBase.startServer(Axis2TestBase.java:36)
>   [junit]     at
> org.apache.ode.axis2.Axis2TestBase.setUp(Axis2TestBase.java:45)
>   [junit] Caused by: java.util.concurrent.ExecutionException:
> java.lang.OutOfMemoryError: Java heap space
>   [junit]     at
> java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:205)
>   [junit]     at java.util.concurrent.FutureTask.get(FutureTask.java:80)
>   [junit]     at
> org.apache.ode.store.ProcessStoreImpl.exec(ProcessStoreImpl.java:542)
>   [junit] Caused by: java.lang.OutOfMemoryError: Java heap space
>   [junit]     at
> org.apache.xmlbeans.impl.store.CharUtil.allocate(CharUtil.java:397)
>   [junit]     at
> org.apache.xmlbeans.impl.store.CharUtil.saveChars(CharUtil.java:441)
>   [junit]     at
> org.apache.xmlbeans.impl.store.CharUtil.saveChars(CharUtil.java:419)
>   [junit]     at
> org.apache.xmlbeans.impl.store.Cur$CurLoadContext.comment(Cur.java:3090)
>   [junit]     at
> org.apache.xmlbeans.impl.store.Locale$SaxHandler.comment(Locale.java:3289)
>   [junit]     at
> org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportComment(Piccolo.java:1190)
>   [junit]     at
> org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yylex(PiccoloLexer.java:4394)
>   [junit]     at
> org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yylex(Piccolo.java:1290)
>   [junit]     at
> org.apache.xmlbeans.impl.piccolo.xml.Piccolo.yyparse(Piccolo.java:1400)
>   [junit]     at
> org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:714)
>   [junit]     at
> org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3439)
>   [junit]     at
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1270)
>   [junit]     at
> org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1257)
>   [junit]     at
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
>   [junit]     at
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:252)
>   [junit]     at
> org.apache.ode.bpel.dd.DeployDocument$Factory.parse(DeployDocument.java:62)
>   [junit]     at
> org.apache.ode.store.DeploymentUnitDir.getDeploymentDescriptor(DeploymentUnitDir.java:219)
>   [junit]     at
> org.apache.ode.store.DeploymentUnitDir.scan(DeploymentUnitDir.java:141)
>   [junit]     at
> org.apache.ode.store.ProcessStoreImpl.load(ProcessStoreImpl.java:608)
>   [junit]     at
> org.apache.ode.store.ProcessStoreImpl$6.call(ProcessStoreImpl.java:461)
>   [junit]     at
> org.apache.ode.store.ProcessStoreImpl$Callable.call(ProcessStoreImpl.java:701)
>   [junit]     at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
>   [junit]     at java.util.concurrent.FutureTask.run(FutureTask.java:123)
>   [junit]     at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>   [junit]     at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>   [junit]     at java.lang.Thread.run(Thread.java:595)
>
> Is there is some solution for my problems? Maybe there is possibility to
> run only bpel-test without other?
> I'm completely noob in rake/buildr.
>

cd bpel-test; buildr _1.2.10_ clean test

Hopefully you shouldn't have any OOM problems.

>
>  Now that I see your exact scenario, I remember having fixed something in
>> the
>> OutstandingRequestManager some time ago. Can you check if ODE 1.2 fixes
>> the
>> problem for you?
>>
>>
> I've checked. There is the same sitution. For replay this scenario, must be
> invoked about 10-15 processes paraller. Maybe this is the point, why it
> doesn't work on your machine but on yours does. I'm still trying to fix this
> bug but I will be thankful for any help.
>

So if you execute it just once it works for you as well?

Matthieu


>
> Cheers, Arek
>

[Arkadiusz Burdach]

Matthieu Riou wrote:
> cd bpel-test; buildr _1.2.10_ clean test
>
> Hopefully you shouldn't have any OOM problems.
>  
Yep. It helps. I've used v. 1.2.4 and it was the problem.
> So if you execute it just once it works for you as well?
>  
That's right. In configuration, which is used in bpel-test works also
paraller version. Maybe the problem is in transactions configuration.
I'll check this.

Cheers,
Arek

[Arkadiusz Burdach]

Hi.

I was on holiday so I didn't look on this bug, but now I'm back and will
continue works on it. Hope, you are happy about it :-)
After investigation of code and tests, I founded, that:

- MessageExchange is in state RESPONSE, because it is older MEX (belong
to one of previous instances of process)
- matcherEvent take this MEX, because value of correlation key is older
- value of correlation key is older because correlation key is
initialized as older
- value of correlation key is initialized as older because two instances
of process got the same message

I've checked this by pmapi and it's true. Two processes stay in state
active and got the same input message.

Some tips why it is done? I remind that problem exists with JBI IL and
WEB IL.
Maybe somebody can tell me, how looks way delivering message to process?

Cheers, Arek

[Matthieu Riou-5]

On Wed, Aug 6, 2008 at 5:26 AM, Arkadiusz Burdach <abr@...> wrote:

> Hi.
>
> I was on holiday so I didn't look on this bug, but now I'm back and will
> continue works on it. Hope, you are happy about it :-)
> After investigation of code and tests, I founded, that:
>
> - MessageExchange is in state RESPONSE, because it is older MEX (belong to
> one of previous instances of process)
> - matcherEvent take this MEX, because value of correlation key is older
> - value of correlation key is older because correlation key is initialized
> as older
> - value of correlation key is initialized as older because two instances of
> process got the same message
>
> I've checked this by pmapi and it's true. Two processes stay in state
> active and got the same input message.
>
> Some tips why it is done? I remind that problem exists with JBI IL and WEB
> IL.
> Maybe somebody can tell me, how looks way delivering message to process?
>

You mean that you're sending twice the same message, resulting in two
processes with the same correlation? We're actually still missing the check
for this and should throw a bpel:correlationViolation.

Matthieu


>
> Cheers, Arek
>

[Arkadiusz Burdach]

Matthieu Riou wrote:

> On Wed, Aug 6, 2008 at 5:26 AM, Arkadiusz Burdach <abr@...> wrote:
>
>  
>> Hi.
>>
>> I was on holiday so I didn't look on this bug, but now I'm back and will
>> continue works on it. Hope, you are happy about it :-)
>> After investigation of code and tests, I founded, that:
>>
>> - MessageExchange is in state RESPONSE, because it is older MEX (belong to
>> one of previous instances of process)
>> - matcherEvent take this MEX, because value of correlation key is older
>> - value of correlation key is older because correlation key is initialized
>> as older
>> - value of correlation key is initialized as older because two instances of
>> process got the same message
>>
>> I've checked this by pmapi and it's true. Two processes stay in state
>> active and got the same input message.
>>
>> Some tips why it is done? I remind that problem exists with JBI IL and WEB
>> IL.
>> Maybe somebody can tell me, how looks way delivering message to process?
>>
>>    
>
> You mean that you're sending twice the same message, resulting in two
> processes with the same correlation? We're actually still missing the check
> for this and should throw a bpel:correlationViolation.
>  

No, I'm  sending two diffrent messages  (with diffrent correlation key
e.g. <id>1</id> and <id>2</id>) but in pmapi I can see that two
instances of process have in variable the same id.

Arek

[Arkadiusz Burdach]

Matthieu Riou wrote:
> You mean that you're sending twice the same message
Ok, I got it. Problem is not in ode but in my testing script, I'm
closing bug and apologizing for my fault ;-)

Arek