Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

General question about JMS system structure

 
Cainiao Zou
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I’m writing a server/client game, a typical scenario looks like this: one client (clientA) send a message to the server, there is a MessageDrivenBean in server to handle such messages. After the MDB finished its job, it sends the result message back to another client (clientB).

In my opinion I only need two queues for such communication, one for input the other for output. Creating new queue for each connection is not a good idea, right? The Input queue is relative clear, if more clients are sending message at the same time, the messages are just waiting in the queue, while there are more MDB instances in server, that should not a big performance issue.

But on the other side I am not quite clear about the output queue, should I use a topic instead of a queue? Every client is listening the output queue, one of them gets the new message and checks the property to determine if the message is to it, if not, it rollback the transaction, the message goes back to queue and be ready for other client … It should work but must be very slow. If I use topic instead, every client gets a copy of the message, if it’s not to it, just ignores the message. It should be better, right?

I’m new about message system. Is there any suggestion about my implementation? Thanks!
 
ntumba lobo
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whether to use a dynamic queue or not to me depends on the calling thread.

If the calling thread, the one sending the request message in the input queue, needs the response message message
from the output queue to carry on its processing then you would need a temporary queue output queue.
This is akeen to a synchronous communication.
On the other hand if the response from the output queue can be process in a separate thread a pair of static queues with
selective consumers on the output queue would more suitable. This is real asynchronous communication.

my 2 cts
 
Cainiao Zou
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ntumba lobo wrote:Whether to use a dynamic queue or not to me depends on the calling thread.

If the calling thread, the one sending the request message in the input queue, needs the response message message
from the output queue to carry on its processing then you would need a temporary queue output queue.
This is akeen to a synchronous communication.
On the other hand if the response from the output queue can be process in a separate thread a pair of static queues with
selective consumers on the output queue would more suitable. This is real asynchronous communication.

my 2 cts


thanks for your answer.
no, the calling thread don't need the response, it's asynchronous.
how about the performance, is it ok for two queues? how about the output queue, should i use topic instead?
 
ntumba lobo
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes it is ok to have 2 queues, this is a messaging integration pattern called "Request-Reply", very common.

Whether to use a queue or topic depend only on how many components are meant to process each message.
If one message is processed by one consumer then it is a queue, if one message is processed by multiple consumers then it is a topic.

Performance wise, if you set the pool size of the MDBs listening on the output queue to a sensibly high value your system should have a decent throughput
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic