• 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

JMS: Request-Reply

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Consider a system where clients send request to server which in turns are processed one by one on the server. As server is done with request it will send acknowledge to client that send the request.
In the JMS solution clients registers to queue as transmitters while server holds the receiver end of the PTP, a queue. The server also registers itself as publisher of the Pub/Sub, a topic. Now clients registers themselves as subscribers and when server has done with queue they have to filter out the message (reply to request) that belongs to that particular client.
Is this sound?
Now, furthermore, I wonder whether there could be multiple queues in order to, say, clusterize the process? Requests would be always routed to the queue that is least crowded.
 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Antti,
We're looking at JMS as a possible alternative to Servlets so are considering something similar to you. I'm trying to get things straight in my mind so bear with me.
I don't really understand why your client would register itself in both a queue and topic. Wouldn't it make more sense to register itself in a queue for a response/request type scenerio. The queue could be open as long as the client's session is open. So then a queue would essentially be a substitute for a session. This would take care of 1)session information 2) security 3)administration- you always know how many clients are connected by the number of queues - you can dissconnect them if you don't like what they're doing (although JMX may be a better alternative)
When you say clusterize - in my mind I think of a critical service that cannot be down vs subdividing a task through multiple servers to cut down the time a task is executed. In the first case creating multiple queues in one JMS server will not be much help if your server crashes. You could create multiple jms servers that are linked (ie roundrobin) so whereever the queue is actually located it will handle the request - ie SwiftMQ.
In the second scenario, creating multiple queues on different JMS servers and sending different parts of your single task/process could speed up your total response time. Although, you have to be carefull about syncronization and the possibility of one server being down... etc.
Oops just read your last line. Perhaps you could have a switch queue that would send your request along to the least crowded queue- if you where going with your model.
I would be really interested on how you implement your system.
cheers,
Yoo-Jin.
 
Yoo-Jin Lee
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
We realized that to "clusterize" a time/intensive activity could be achieved by using a queue. Multiple clients could be attached to the queue and since only one message is sent to one client, the jms server would in effect spread the load around.
hope this helps.
Yoo-Jin.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the JavaSpaces approach is more appropriate for load distribution in clusters. It should be more nearly fail-safe than JMS.
JavaSpaces is part of the JINI package but you don't have to use all of JINI to benefit from JavaSpaces.
Bill
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic