Welcome to the Ranch. I'm sure some bartenders will be along soon to modify your post. You made a couple mistakes. Always use code tags when posting code and never, never, never post copyrighted code. Generally speaking, you can't expect people here to read through hundreds of line of code, so it's a good idea to just post the important parts of the code ... maybe 20 to 30 lines. That helps with copyright issues too.
Meanwhile, what do you mean by multiple requests? Do you mean several readers reading from the same queue? That's always possible. In a normal point-to-point mode, each reader gets a different message, so having multiple readers just can speed up how fast messages are consumed. In a publish/subscribe mode, all active readers (now called subscribers) that have registered their interest in that queue (now called a topic) will get every message written (published) to it.
Joined: Mar 02, 2009
Thank you for the advice. I really appreciate it.
Yes, we are trying for several readers reading from the same queue.
I read in below link that JMS cannot handle multiple requests and the code has to handle multiple reading on the same queue. Is it correct?
I looked at the link you gave, but I'm not sure exactly what section you are referring to. Yes, you can have multiple queues and you can have several readers for the same queue.
JMS has several constructs. You use a ConnectionFactory to get a Connection, and the Connection to get the Session. When I was just starting out with JMS (and only wanted a single reader), it seemed like a huge burden to just get to the point where I could read a message. However, the advantage is you can create one Connection, which is guaranteed thread-safe, and use it to create multiple Sessions, which are not guaranteed thread-safe. You can create many readers, each in a separate thread, to read from the same queue. Each will get a different message. They just share the work of processing.
In the J2EE world, the easiest thing to do is just create a Message Driven Bean. This bean will handle reading messages from a specific queue, without forcing you to even deal with Connections and Sessions. You can then configure the number of readers just by configuring the number of beans through your app server administration.