-
1. Re: Delayed Message Sucking
I didn't understand your topology.
Can you explain it again in more detail? -
2. Re: Delayed Message Sucking
One other thing. My consumer services are running 5-10 user threads each so they will process 5-10 messages simultaneously.
-
3. Re: Delayed Message Sucking
------------- | L1 L2 | <-- linux cluster, 2 nodes, with clustered Queues, Q1 and Q2 ------------- ^ ^ | | W1 W2 L == linux JBossAS 4.2.2.GA with JBM 1.4.0.SP1 W == Windows JBossAS 4.2.2.GA. Not clustered , running consumer service
Identical services running on L1 and L2 each post request messages to a clustered queue (Q1). The thread that posted a message then calls MessageConsumer.receive() on a response queue (Q2).
Both W1 and W2 are connected to L1 using ClusteredConnectionFactory. Therefore, all messages posted to L2 are sucked over to L1 and consumed by W1 and W2. W1 and W2 post response messages to response queue (Q2) on L1. The MessageConsumer.receive() called by the L1 service receives the response messages it is waiting for. The MessageConsumer.receive() called by the L2 service never returns. The response messages that L2 is waiting for are stuck on L1-Q2. Eventually, they are sucked over to L2-Q2 and L2 finally receives them.
-
4. Re: Delayed Message Sucking
"chip_schoch" wrote:
W1 and W2 post response messages to response queue (Q2) on L1.
Ok so you've posted your messages to clustered response queue Q2 on L1
The MessageConsumer.receive() called by the L1 service receives the response messages it is waiting for.
Yes L1 should receive all the response messages
The MessageConsumer.receive() called by the L2 service never returns. The response messages that L2 is waiting for are stuck on L1-Q2.
If the messages are on Q2 on L1 the consumer on L1 should receive them all. A clustered queue *always* favours local consumers. I wouldn't expect the consumer on L2 to receive any of them
Eventually, they are sucked over to L2-Q2 and L2 finally receives them.
I guess this happens when you close the consumer on L1?
If you want your response queue to be only usable by your connection, you can use the distributed request/response pattern.
I.e. create a clustered temporary queue and pass that as the "replyTo" header in the message.
When the message is consumed, a reply is sent back to the destination that's specified in that header.
Sounds like that's what you want to do. -
5. Re: Delayed Message Sucking
Have a look at org.jboss.test.messaging.jms.clustering.DistributedRequestResponseTest for an example of how to do this.
http://anonsvn.jboss.org/repos/messaging/branches/Branch_Stable/tests/src/org/jboss/test/messaging/jms/clustering/DistributedRequestResponseTest.java -
6. Re: Delayed Message Sucking
If the messages are on Q2 on L1 the consumer on L1 should receive them all. A clustered queue *always* favours local consumers. I wouldn't expect the consumer on L2 to receive any of them
Hmm... Sometimes it receives all, sometimes some messages. I have been testing by sending 10 messages at a time, 5 are queued to L1-Q1 and 5 are queued to L2-Q1. Each L server has a service that has a local thread pool in which each thread sends a message then calls MessageConsumer.receive() on Q2. All the response messages are queued to L1-Q2 but only half of them are comsumed by the L1 MessageConsumer.receive() threads. The others get consumed by L2-Q2 MessageConsumer.receive(). In the cases when they are not being consumed there is no consumers on L1-Q2 but 5 consumers on L2-Q2. I assumed they should be getting sucked over to L2-Q2. I wonder why they are sometimes.
Could you elaborate on you suggested solution a bit? When you suggest using a clustered temporary queue then aren't I losing my persistence on the response message? Maybe I don't need it? -
7. Re: Delayed Message Sucking
Tim,
Thanks once again for your help. Using the Temporary Queue cleared up all my issues. It works great now.