Clustered RESTful queue thoughts

[bill.burke]

In my single node RESTful queue impl, i have a pool of message listener consumers.  When a message is consumed, these listeners place the message within a local, in-memory, java.util.concurrent queue that can be pulled statelessly and acknowledged sessionless.  (the consumer blocks until the message is acknowledged.  On timeout it reques the message in the local java.util.concurrent queue).

This just won't work in a cluster as it seems that Hornetq depends on consumers generally being a static thing to *efficiently* deliver messages.  Hornetq assumes that consumers will consume.  This makes sense.  This architecture requires minimal book-keeping and handshaking.

One thought I have is to fake out the consuming client to bind it to a specific session.  Since the client is required to follow links from responses to get new messages, you could stick the client onto a speific session on a specific node.  The queue session could be married to the Keep-Alive of the socket connection between the client and server.  When this socket is terminate, the session could be closed.

But, what's the f'n point of being purely RESTful here?  Can pretty much have the same interactions with a session-based approach.  Would just need a session resource that could be DELETEd when the client-consumer was done.

[clebert.suconic]

I'm not I understand this completely.. but wouldn't you need to setup consumer window size = 0 for slow consumers?

http://hornetq.sourceforge.net/docs/hornetq-2.0.0.GA/user-manual/en/html_single/index.html#flow-control.consumer.window

[bill.burke]

So, a window size of 0 would allow me to pull the cluster for the next message?

[clebert.suconic]

It wouldn't cache messages on the client. It would always go against the server.

What I understood is the caching was being a problem for your case.

[bill.burke]

BTW, i'm trying to make RESTful consumers stateless, sessionless, through a pull model.  For single node, one consumer receives the message and puts it within an in-memory local java.util.concurrent queue.  A sessionless client asks to consume a message from the server and just pulls from this in-memory queue.  The consumer blocks until the message is acknowledged by the client.

In a cluster, if  a specific consumer is assigned a message, i don't have a great way of knowing which consumer to route the remote client to.

[bill.burke]

Clebert Suconic wrote:

It wouldn't cache messages on the client. It would always go against the server.

What I understood is the caching was being a problem for your case.

A restful client would be stateless and sessionless, with no local code managing the connection to the server.