• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

General question about JMS system structure

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic