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

Reply via email to