5 Replies Latest reply on May 3, 2010 1:24 PM by Bill Burke

    Clustered RESTful queue thoughts

    Bill Burke Master

      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.