I still don't quite follow why you need to use a temporary queue - you could just use a real queue and send around Strings so anyone can send to component 3.
By all means use the string constructor for ActiveMQTempQueue - though be very careful to keep them very unique - and there could be bugs you hit consuming from a temporary queue without actually using the createTemporaryQueue() method. On 1/11/07, MrRothstein <[EMAIL PROTECTED]> wrote:
Daryl Richter-3 wrote: > > Ah, ok, then I think you could do it this way: > > A Component 1 sends a message request/reply to a specific channel, we'll > call it channel A. At this point JMSReplyTo is Component 1's temp queue. > > Component 2 is listening to Channel A. With each incoming message you > start > a new thread, format the message for the external system and send. This > thread then polls the outbound external queue until it sees it's message > (by > correlation id) at which point it pulls it off, reformats it and sends it > back to Component 1 via the JMSReplyTo. > > Something like ServiceMix might well help you here in that you might not > have to write the threading. You just specify that you have n instances > of > Component 2 listening on Channel A and it takes care of their lifecycles. > (Component 2 of course would need to be thread-safe in itself, but that > shouldn't be an issue here.) > I found that if I cheat just a little, I can get it to work :). I can instantiate an ActiveMQTempQueue directly using the string constructor. The string would be the name of the temp queue. I realize this is completely breaking with the spec, but I've also seen a similar way to do it with WebSphere MQ. Sooooo, I'm assuming there is something similar that can be done with most jms implementations. Thanks again for your help. -- View this message in context: http://www.nabble.com/Working-with-temporary-queues-tf2944057.html#a8270892 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
-- James ------- http://radio.weblogs.com/0112098/
