Wow, that was fast. I'll give it a try. Klaus.
gnodet wrote: > > Oops, sorry. > This should be fixed now. > > On 8/23/06, Klaus Alfert <[EMAIL PROTECTED]> wrote: >> >> >> Guillaume, >> >> the saga continues... >> >> After changing to the standard processor WebSphere MQ works, but only for >> one message. Our next testcase sends a bunch of messages, but never >> sucessfully. So I recuded the set of messages to only two messages. But >> receiving the second message from NMR which shall be enqueued to the same >> Queue, results in Exceptions. These exceptions vary from case to case, >> including the hint that the Session is already closed. >> >> I suspect that this is a threading issue: The session variable within >> StandardProviderProcessor is member which is initialized during process >> and >> is afterwards set to null. So, if a single instance of >> StandardProviderProcessor is used in several threads concurrently, this >> would result in nasty race conditions. This would also explain why it is >> possible to transport say 5 of 20 messages but not 2 of 2 successfully. >> Our >> examples run on a two processor Solaris machine. >> >> Klaus. >> >> >> Ah, good point. Our simplest example is now running. So let's move on to >> next tests. >> >> Thanx for your help. >> >> Klaus. >> >> >> >> gnodet wrote: >> > >> > You may want to try with the processorName="standard" attribute on the >> > JMS endpoint. The default processor uses multiplexing, which is not >> > available on all jms providers. >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5943288 >> Sent from the ServiceMix - Dev forum at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > -- View this message in context: http://www.nabble.com/Exceptions-in-servicemix-jms-with-WebSphereMQ-tf2141329.html#a5943628 Sent from the ServiceMix - Dev forum at Nabble.com.
