OK, for the benefit of Mr. Vanthienen and anyone else who may be following this thread, here is http://www.nabble.com/file/p23819496/seda-jbi-stuck.txt a thread dump of the system in a stuck state. If you are trying to follow the dump in detail, you should be aware that
1. This is an instance of the Camel service engine in which I have substituted Camel 1.6 for the Camel 1.4 that is included in the normal download. 2. The Camel SE is running inside an OpenESB JBI container, not ServiceMix (hence the presence in this dump of packages such as com.sun.jbi.messaging). For those who don't care about the details, but might be having similar problems, there are a few things you may want to know: 1. Mr. Vanthienen's suggestion of trying direct URIs in place of SEDA fixed the problem; this is probably something you should always try if you're having SEDA problems--I know I will. In this example, changing the two instances of "seda:mbQueue" to "direct:mbQueue" made the problem go away. 2. This problem was surprisingly hard to reproduce. For example, by the time I got around to writing this report, I had already moved the XSLT-splitter logic to another (in-out) JBI service. In this form, the logic worked even when I had SEDA URIs throughout. Evidently, the cause of this problem is not as simple as hooking a splitter to a SEDA to an in-only JBI. So, unfortunately, I can't tell you what constructs to avoid; I'll just reiterate that if SEDA queues appear to be stuck, try making some of them "direct." -- View this message in context: http://www.nabble.com/JBI-In-Only-Exchange-Never-Completes-tp23732734p23819496.html Sent from the Camel - Users mailing list archive at Nabble.com.
