[cptnkirk]

Same here. SwiftMQ is a top notch product and they have a clustering system that works very well. I guess what people are asking around here is what should the JBoss clustering method/system be and how should it work?

People in general agree that "clustering" of some sort should be provided. Many commercial MOM providers have some sort of clustering, however no two seem to offer it in the same way. A lot of people like Swift which uses a router approach. In short you send a message to a destination on a router. If the destination doesn't live on that router, it will find some way to get there (sometimes via multiple hops).

Other systems I've heard of work like an App. Server plug-in to a web server. This means that load can be distributed across many web servers and many application servers with the plug-in being the smart agent doing the routing. And I'm sure there are still others.

Correct me if I'm wrong, but JBoss is still in the phase of trying to figure out which paradigm to use. Some people here (myself included) would like to see JBoss use a routing tech like Swift. Others think that clustering of JMS resources in a similar way to how J2EE clustering is done is the way to go.

Some people want "clustering" support "soon", presumably so that it can be said that JBoss includes it (because businesses require it, etc). This need also has the potential to influence design choices.

From a functional perspective, what features do you need to have with JMS clustering? What features would be nice to have? When do you need them? If you had a choice between getting something usable (but not optimal) now or having to wait a little while what would you choose? If you already having something in production, what type of clustering does it offer? Do you have a home grown solution, if so how does it work? Does it meet your needs? How would you like the JBoss solution to be "better"?

[integ]

Ok i have some functional requirements input :)

The points of failure that iam concerned about while using JBossMQ and MDBs are the following :
1.Failure when a message is send to the queue
- say a queue session is not obtained
2.Failure when a message sitting in the queue is handled by he QueueManager - i will need to failover to another queue
3.Failure when the MDB processes the message - i will need clustered MDBs.

I would like to have this : queues are replicated and MDBs clustered on multiple nodes.When a message comes in on a queue on one node and it fails, it hops to the next available node( based on a loadbalancing algorithm )i would like it to keep hopping between nodes for a configurable number of times - say = max retry specification.

We are using HA-JNDI in the current non-MDB clustering service, i wouldnt mind a similar solution, however routing is good too.I will opt for an immediate usable solution for now as long as it becomes optimal later on :)

Thanks,
Rakesh.

[schaefera]

I am still struggeling with what JMS clustering means. From a J2EE stand point it means failover and load-balancing by providing the client with a logical view to a bunch of similar app. servers.
So for JMS this means that you can connect to a logical JMS server and still get the same messages, right?

For failover this can be implemented by providing a decicated or primary JMS server. This will receive all messages and provide them as well. Any backup or secondary JMS server will be informed about new or delivered messages in the case the primary goes down. Then a secondary will promote itself to become the primary.
To achive the logical view all ConnectionFactories to all other servers will route the message to the primary or will receive messages from the primary. For the MDBs the JCA JMS Resource Adaptor will pick up messages from the primary server.

For load balancing I don't see a way to implement this and to gain performance improvement. For non-durable subscriptions the message would just be sent to all JMS server of the cluster. For the other I would think that all JMS servers would receive messages but they would have to lock on a message before it can be delivered to a client. If the message is delivered the lock and all messages on the other servers are removed. Otherwise only the lock is removed and the message still waits to be delivered. But the management of the messages and locks would outweight the benefits (IMO). Also each server would inherit the problems with resource constraints like PMs, message caches etc. on a heavy used JMS server.

Have fun - Andy