I looked at the code and it looks like this is just badly written protocol / error handling. The bug will go away if you somehow disable caching.
The problem is that it reads a short value from stream, which is then used as index in array (the array size is dynamically set during protocol negotiation). Index is not checked for out of bounds condition and there is no error handling / recovery. In my case one message (out of 80K) was never delivered to the recipient. The most unfortunate thing is that this part of the code (caching) is the same in 5.0 and 5.1 code. 5.x uses v3 of amq protocol, but the caching logic is in common package. So I guess that this problem will not go away with upgrade to 5.1. The "good" thing is that it does not happen a lot. Piotr Jagielski wrote: > > Gert, > > My route is : > > jms -> camel processors -> jbi endpoint > > Where jbi endpoint is a sync webservice. So, after calling it, Camel > component does some work, but it hangs, since DeliveryChannel.sendSync > never returns. > > Maybe the problem is related to CamelTemplate.send? I use it because name > of jbi endpoint is passed in runtime, but maybe could be static. > > Is the ActiveMQ stacktrace somehow related to the problem? > > Regards > Piotr > -- View this message in context: http://www.nabble.com/Servicemix-Camel-problem---ToJbiProcessor-hangs-tp18651622s22882p18740824.html Sent from the Camel - Users mailing list archive at Nabble.com.
