camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Issue with JMS Temp Queues (Tibco EMS)
Date Wed, 16 Mar 2011 12:00:39 GMT

I think temp queues won´t work for your case as I think you can not 
explicitly set the name of a temp queue. It is rather like queueName = 
createTempQueue() so you would need to transfer the name to the peer.

One thing is that you could use dynamic queues. These can be created on 
the fly if the JMS server allows it. The problem is that these queues 
are not bound to the lifecycle of the creating connection. That means 
you have to care for removing them manually while temp queues are 
removed automatically.

You could also try to explain what exactly you are trying to achieve 
with that. Perhaps there is a completely different way that also works well.


Am 14.03.2011 14:17, schrieb enalposi:
> Hallo Christian -
> Right, we are using temp queues for responses, but need more control than
> standard req/resp. The response may not just be synchronous but result in
> several messages (this is not uncommon in the financial/analytics world and
> in general helps creating dynamic interfaces that incrementally handle
> results as they come in)
> Installing dedicated queues or responses is not desirable, since we don't
> want to manage multiple queues per service (would ultimately be 100s). Hence
> we want to define one queue for incoming requests (which we multiplex on the
> server and can then be dispatched to processing resources on a grid, etc)
> and have dynamically created channels (i.e. not requiring to file change
> tickets and comply with a tedious review and justification process)
> To give the configuration of the routes is somehow difficult, as they are
> dynamically created based on an internal framework that translates logical
> destinations into actual routes. For outbound it goes something like this:
> from(_from).setExchangePattern(_pattern).threads(_poolSize).process(_processor).to(_to).setId(_routeId)
> _from in this case is a 'direct:' endpoint and _to a 'jms:' destination.
> Sending is done with a ProducerTemplate.
> _processor is one of our framework components that for example performs
> custom serialization for x-platform.
> Getting back to my problem In other words: Is it possible to use well
> defined temp queues with straight Camel, or is it somehow abstracted away so
> that a given temp Camel route may result in a random effective JMS endpoint?
> Cheers!
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Christian Schneider
CXF and Camel Architect
SOPERA - The Application Integration Division of Talend

View raw message