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 Wed, 23 Jul 2008 23:28:44 GMT
On Tue, Jul 22, 2008 at 9:03 AM, Arkadiusz Burdach <abr@touk.pl> 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:


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?


>  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
>> 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

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