ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: FATAL in BpelRuntimeContextImpl
Date Mon, 21 Jul 2008 18:17:23 GMT
On Mon, Jul 21, 2008 at 3:16 AM, Arkadiusz Burdach <abr@touk.pl> 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,


> 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

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