ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arkadiusz Burdach <...@touk.pl>
Subject Re: FATAL in BpelRuntimeContextImpl
Date Tue, 22 Jul 2008 16:03:51 GMT
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

View raw message