Hi Yuvaraj, to answere each of your questions directly. -- produce/consumer are on same JVM? In the simple setup i am using to try and debug this there are two JVMs. Threads in the first one only act as a producers, putting an initial set of messages in the queue. Threads in the second act as both a producer and consumer, consuming messages from the queue and occasionaly adding some of its own messages back to the queue.
Having debugged the application further i can say that when JVM 1 (only producers) places items on the queue they appear in the web browser view of the queue but consumers in JVM 2 (which has both producers and consumers) remain blocked. Only when JVM1 hangs up its underelying jms connection to the broker do the consumers in JVM2 start to recieve. From that point everyhting appears to work as expected. :-S -- do they create separate connections? Each JVM instances creates a single underlying connection. Each producer/consumer creates its own session from the underlying connection. -- do they do connection.start() after creating connection? Yes, The underlying connection is created during my intial setup code (prior to any producer/consumer being created). It is immidiatly followed by connection.start(). Why don't you just try with single producer and consumer to make sure there is no threading problem? Its hard to isolate the code enough from the rest of the application to do this but initial attempts suggest that having a very low number of producer/consumers works as expected. That is why i was wondering if it could be some sort of flow control on the number of sessions? Why don't you try without filter if something is wrong over there? I have done this as you suggest by using seporate queues for each message type instead of a single queue with selectors. The behaviour remains the same. Thanks for your time, Chris -- View this message in context: http://activemq.2283324.n4.nabble.com/JMS-Messages-not-consumed-till-producer-connection-close-tp3985842p3989822.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
