I need to asynchrously transmit *different* messages (i.e. no pub/sub) to possibly thousands of clients on a WAN. I'm evaluating whether JMS queues are the right solution for this. I don't understand JMS implementations enough (leaning toward activeMQ) to know whether each client maintains an open socket with the provider. If so, it doesn't seem this would work, as the provider would be overloaded with open sockets. I was thinking to have a pool of threads manage synchronous calls to the set of clients, but it seems this should already be available. Does anyone have insight on this particuliar type of problem?
- Posted by: Rick Badertscher
- Posted on: April 10 2006 00:23 EDT
Even if the underlying middleware implementation would support this level of scale, I'm not sure that you'd want to try to manage that many JMS queues. The user experience for JMS management consoles will generally not allow you to manage thousands of queues easily.
One work-around would be to reduce the number of queues by logically aggregating the request types and have a controller / handler that would listen to a single queue (assigned to a type of work) and farm out the work more specifically based on an embedded message type or sub-topic.
Admittedly, you are extending middleware to do this, and I usually try to avoid that, but in this case, it gives you more flexibility of how you specify your destinations. They don't necessarily have to be expressed in terms of JMS queues, and you can write a custom manager UI that is better suited to manage the number of destinations you have.
you said "..asynchrously transmit *different* messages to possibly thousands of clients on a WAN" .. I'm not sure why you said ("no pub/sub"), .. because your using JMS which is maining for Publish/Subscribision services..and those clients should simply be a listeners on a queue/topic(in your case you may need a clusterd JMS Server for the user-load).
If you really meant what you said in your requrement to "tranismit messages"...then you don't need a Queue on your end anyway right? think about it... your system will send messages to the client...your not sending messages async to your own queue??
please explain more maybe i can help ,ive been where ya are when i first learned about it..:).
Whatever technology you use (web services, RMI, CORBA, JMS) you will use sockets for the client to talk to some kind of server. So worrying about the number of sockets isn't an issue really.
Dealing with 1000s of clients is pretty easy these days with a JMS provider such as ActiveMQ; the only real limit is how many sockets your OS allows per JVM; on modern unixes this is often > 10,000. If its low, just use lots of JVMs networked together.
If you do go ahead with JMS and ActiveMQ in particular; you need to describe what quality of service you want & if you need persistent messaging or not. If its typically GUI clients then temporary queues are often fine (which survive for the duration of the client and don't require management). If you are using durable messaging then you could use a client ID on the messages and filters to avoid having too many queues than is easy to monitor and manage.
Fuse: the Open Source SOA runtime