Does HornetQ REST interface work in EAP 6.1 cluster?

[mgznt]

Hello,

I'm trying to use the HornetQ REST interface in a JBoss EAP 6.1 cluster. With only a single active node, consuming messages works fine through the pull mechanism.

As soon as I activate the second node, most "consume-next" requests get a HTTP error code 405. Some requests work, though (HTTP 200).

I suspect that subscriptions are not mirrored to all cluster nodes and whenever the "wrong" node gets a consume-next request, it returns error 405 (?)

Is the REST interface supposed to work in a clustered environment? If so, what must be configured?

I'm using a WAR with the attached web.xml and hornetq-rest.xml to access the HornetQ REST interface.

Thank you,

Michael

[mgznt]

I've worked around the problem by creating a second server-group "single-server-group" with only a single server. The group uses the same "full-ha" profile as the main cluster-server-group. Thus the groups' messaging subsystems are connected and messages are automatically routed to both server groups.

The WAR that contains the REST interface is only deployed on the single-server-group. Now all subscriptions to the REST interface are served by the same host. No more HTTP 405 status codes are returned to the clients. It also means that the REST interface is not clustered, i.e. no load balancing or automatic failover is possible. For us, that's an acceptable tradeoff.

[jbertram]

Do (did) you have an HTTP request load-balancer in between your REST clients and the EAP 6.1 cluster?

You're correct that the consumer state for the REST client is not mirrored across the cluster.

[mgznt]

Yes, we use mod_cluster for load balancing. It now redirects the REST clients to the single-server-group.

Judging from the code, the REST interface uses the HornetQ API to manage subscriptions. Are there any plans to add support for mirroring the subscriptions across the cluster nodes?

[jbertram]

Yes, we use mod_cluster for load balancing. It now redirects the REST clients to the single-server-group.

Your solution is valid.  Another way to solve the problem I think would be to enforce sticky sessions where the first request would be load-balanced but all subsequent requests from that client would go back to the same server.  I'm not very familiar with mod_cluster so I'm not 100% it supports that type of functionality but I know other load-balancers do.

Judging from the code, the REST interface uses the HornetQ API to manage subscriptions. Are there any plans to add support for mirroring the subscriptions across the cluster nodes?

There are no plans to add support for mirroring subscriptions across the cluster nodes at this time.