On Tue, Jul 22, 2008 at 9:03 AM, Arkadiusz Burdach <[EMAIL PROTECTED]> 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 >> >> >
