JBossMQ HA configuration

[venukb]

Jboss Version : 4.2.2
Cluster - 3 Node

When I start JBoss with 4.2.2 configuration, JbossMQ by default starts as a HA-Singleton Service.

I have 2 MDB running on all the nodes in the cluster listening on the default topic and queue

Message published on a queue by a servlet running the same JVM is load balanced and the message published on a topic is received by all the nodes

How do I make the servlet send the message to the MDB running on the same node ! (I need this communication to be sticky)

I do know that I can have a non HA configuration of JMS which solves this problem; However for other scenarios I need the functionality of a HA JMS as well!

Is there a way to create destination (topic/queue) which work on the same node and also have destinations which are load balanced?

[venukb]

Sorry I mean "start JBoss with all configuration"

[jay.howell]

The answer really is no. Because JBoss mq is running as a singleton, it means that there's only one instance of mq running in the cluster. So lets say you have machine A, B, and C and A is the master. A will be the only one in the cluster running jboss mq. The rest of the machines have MDBs that connect to A and listen for messages. When your servlet sends a message to the ONE MASTER server(which is the only one running MQ), one of the MDBs on one of the servers will pick it up. Here's the options I see for you...

1. Move over to JBossMessaging. http://www.jboss.org/jbossmessaging/
It already solves your problem. In JBM, the messages are load balanced, but will be picked up by consumers on the local machine first. This solves the behavior problem.

2. Filter your messages by correlation id
Set the correlation id or something else in the message your servlet generates, something that you can use a message selector on in the ejb. So lets say that you are using the ip address(or something that identifies that node). You set the correlation id in the message that your servlet sends and then you set a selector that only selects that correlation id. Since the servlet and the ejb are on the same node, you should be able to set an environment variable or use something that's already in the environment that is distinct to that node for the correlation id.

3. I have seen poeple run JBossMQ locally(in the deploy directory) and also as a HASingleton(net result is that two JBossMQ services run). Then the messages that they want consumed by the cluster, they send to the singleton instance, and the ones they want consumed locally, they send to the local instance. I will tell you that it is a configuration and code nightmare though. I though I would bring it up, in case you were considering it. I would not recommend this approach, but others have successfully done it.

Personally, If you are in development, I'd move to JBM. JBossMQ is currently in maintenance and is going away in JBoss 5.x. I would start to make the move over to JBoss Messaging now. I'm not saying that there will be an easy migration path from JBM 1.4.0SP3 to JBM 2.0(included in jboss 5.x), but it will be easier as far as design. If you make design decisions based on a singleton messaging system, you may have to go back and undo those design decisions later.

Hope this helps,
Jay:)

[venukb]

Thanks Jay for the quick response :)

You seem to have pointed out everything that I thought of (especially point 2 and 3).
However I never knew that JBM has a optimized load balancer.

Point 2 was something I tried before posting here; but I couldn’t find a way of applying dynamic selectors on MDB. I had it set in the annotation!

If there is a way of dynamically setting the selector, this approach looks clean (I could even get some unique information about a node from JMX and set it)

Point 3 is something I wanted to try out, but will probably not after seeing your reply :)

We are still in development and definitely targeting JBoss 5.0.

However JBoss5.0 CR2 has its own issues
1. Slow startup
2. I had a tough time resolving the PostOffice error while setting 5.0 Cluster (Finally resolved by setting a different value for jboss.messaging.ServerPeerID
3. No farming service
4. We use JDK 1.6 and JAX-WS Web services doesn't work out of the box

I am sure some of these are going to be resolved by GA release, but I want one final opinion from you

Should I go with JBM on JBoss 5.0 ?
or
Should I try to integrate JBM with JBoss 4.2.2

(Is the optimized load balancer feature in JBM dependent on JBoss?)

Thanks
Venu

[jay.howell]

It really does depend on your rollout date. I would not count on all of that jelling together for at least another month or 2. JBM 2.0 is still not finished yet.

If you had to roll out in the next 6 months, I'd go with JBM 1.4.0sp3(It's pretty solid). If your date for rollout is going to be longer, you can probably wait for the GA of JBoss 5.x.

This is the way that failover and load balancing work with JBM 1.4SP3.
http://wiki.jboss.org/wiki/JBMCluster

Some of this will change in JBM 2.0 though, but it's not at all clear yet what will change or how it will pan out.

Jay:)

[jay.howell]

I'm sorry. I mispoke. JBM 2.0 is not going in jboss 5.x. JBM 1.4.1 is going in jboss5.x. JBM 2.0 is going to be something like jboss 5.1. So you should have a smooth transition from jbm 1.4.0 and 1.4.1. The difference for 1.4.1 is that there is no longer a dependency on the mbean structure inside the app server. Since jboss 5.x is pojo based, JBM had to change the implementation so that it is pojo-ified. This is a better change, because now JBM can work outside of the container. Makes it easier to test and makes it easier to embed somewhere else.


I would recommend upgrading to 4.2.3(http://www.jboss.org/downloading/?projectId=jbossas&url=https://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=614346) and installing JBM 1.4.0 sp3(http://www.jboss.org/jbossmessaging/downloads/).

This is stable and has been out in the community for a while. It should do well for you.

Jay:)

[venukb]

Yes Jay, I am sticking with the stable 4.2.3GA
Also I did get JBM 1.4SP3 up and running (replacing JbossMQ) and saw the "optimized" load balancer is action.

Thanks again for the guidance.

[jay.howell]

I think that's a very wise choice to stay on 4.2.3. One point to note though about the load balancer in JBM 1.4.0 sp3. There are two different components that load balance.

1. Round Robin connection when using the clustered connection factory. What this means is that if you are using the clustered connection factory, each connection you request you will get a connection to a different server. Messages being consumed or being added will go to that server.

2. Suckers - the suckers pull messages from one machine to the other to try to balance the load. So in a clustered queue, one machine will pull from the other. But it will only pull messages if it's queue is empty. So the queue has to be completely empty in order to start to look for messages elsewhere.

Cautions and Warnings about using a clustered queue:

1. Selectors don't work clusterwide. This means that while you may add a selector, it will only select from the server that it is connected by. If you have a consumer that has a selector and the server queue that it is connected to has messages, but doesn't match the selector, no load balancing will take place. Because there's still a message in the queue, it just doesn't match your selector. It's important to understand that selectors don't work in a clustered scenerio, because they are the solution to many jms antipatterns.

2. Queue Browse doesn't work clusterwide. Since this is a peer to peer server setup, there is no way to browse the entire queue, because a small piece of that queue is on each server. I suppose we could write something that would gather the queue contents from each machine and send them back, but by the time they got back the data would be stale. A clustered queue-browse is just not feasible with the current setup.

Hopefully you won't fall into any of these gotyas.

Jay:)

[venukb]

I was hoping very much on the working of selectors in a cluster (In fact I read the same point on the JBM wiki this morning :) )

It was one reason of wanting to have a JBoss MQ in HA (Not sure if the selector behavior is same in MQ as well)

There are some notifications which flow in from a external entity into the enterprise tier and this needs to pushed into the web tier so that its pushed again to the browser (using DWR/cometd).

I was relying on the fact that the web tier could listen based on some selector say (login ID) and we apply that selector on these external notifications so that is picked up by the node where he has logged in.

I was under the assumption that clustered destinations are not bound to any server and expected it to be picked by the right consumer

Guess need to find an alternate way to solve this :)

Also just to be clear, Round Robin and Sucker works only on "Clustered" destinations right ?