On Thu, Dec 22, 2011 at 11:46 PM, Mark Borner <mark.bor...@zurich.com.au>wrote:
> > I'm trying to use Camel (v 2.6.0) JMS Request/Reply with Websphere 7 using > Websphere MQ. I'm successfully able to put the request message onto the > queue using the following URI: > > > jms:queue:inboundQueue?connectionFactory=#connectionFactory&taskExecutor=#taskExecutor&transactionManager=#transactionManager&cacheLevelName=CACHE_NONE&replyTo=outboundQueue&requestTimeout=120000 > > Note: I have to use cacheLevelName=CACHE_NONE in order for this to work on > Websphere. > We work on WebSphere AS 6.1 in combination with WebSphere MQ as well, and I also had trouble with the cache settings. Lowering cache level to CACHE_NONE, seemed to solved the issue at first sight, but this leads to intermediate JMS session resets, and in our case, possible lost messages because we did not use any durable subscriptions. A colleague of mine warned me for some problems he had with durable subscriptions in WebSphere MQ, so I did not even try that particular setup. Bringing the cache level to CACHE_CONSUMER solves the problem with lost messages, but this is not compatible with the default WAS work manager. The latter uses some kind of asynchronous internal beans, which REQUIRE closing JMS connections at the end of each call. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fasyncbns%2Fconcepts%2Fcasb_asbover.html The trick to solve this: don't use the WAS work manager, but use some simple Spring thread pool based executor instead. So, maybe you can give this a try for you as well .. Tung
