This content has been marked as final. Show 2 replies
The current JMS spec does not require providers to support multiple consumers on the same queue. JMS 2 may change that and in practice most providers actually support it anyway. If you are going to do it then you should probably use selectors. Don't forget that JMS' best use case is asynchronous integration. If you want synchronous communication with return results then maybe consider webservices or remote EJB calls.
1) P2P messaging, in the example, for one pair of peers, there one producer and one consumer for one queue created. As a normal application, communication goes two ways, one send one message to the peer, the receiver processing the message and then reply with some message. My question is, do we have to create two queues? I feel like I have to, because the destination is not the peer, but is the queue itself.There's a well-known messaging pattern called "request-response" messaging, where application A sends a message to application B and waits for a response to be sent back. If this is what you require then this can be easily implemented in JMS, using a normal queue for the request and a javax.jms.TemporaryQueue for the response.
For one client side, can the consumer and produces be created in one session?Yes, though if you use a transaction you need to remember that the producer doesn't actually send the message until the transaction is committed. So you can't send a message and then wait for the response within the same transaction.
2) The example given is one one destination in one session in one thread. My question is, for good practice, does it make sense to create multiple producers on multiple queues(topics) in one session?Yes, so long as you're not using those multiple producers from different threads at the same time. You can only use "the resources of a session" from one thread at a time. If you need to use multiple threads, create multiple sessions.