2

I would like to put together a system where clients obtain messages from a REST API, but with the producer being able to use the semantics of a message queue: e.g. ordering of messages, a destination mailbox, etc.

I figure I can have one message queue per client.

When a client connects to one of N stateless webserver/REST endpoints to GET new messages, any new messages gets dequeued from the client's mailbox on the message queue, packaged up and sent to the client as a response to the GET.

I think there are some problems with this approach, though.

Seems each REST request would make a new connection to the message queue (or possibly there is some pool of connections - but mailboxes would have to be efficiently switchable in the connection)

Furthermore, I am not sure how to handle the case when a client gets a list of messages as a response to a GET, dies halfway through processing them, and has to re-request messages it has already been given. The queue would have to have some level of persistence, and some ability to rewind.

My questions are: am I going down the right path here? What can I do about these issues and am I missing any other pitfalls? Or maybe there is a completely different way to do this that might be more optimal?

1 Answer 1

1

It is not because you use the semantics of a queue that you need an actual queue to back your REST service. It is very possible to create a service that uses queue-like semantics, but that is backed by a database.

In that case, you would not have a new connection per REST request but would take advantage of connection pooling. Using a database also means messages are persistent so a degree of rewinding is possible. As for dying receivers, a request to get messages could send a list of messages to the client in one request and mark these as sent in the database. The receiving application could then acknowledge receipt of a message by individual REST calls. A job running intermittently could re-mark messages to be sent to the client if no acknowledgement was received after an amount of time.

1
  • The server does not have to mark questions as sent in the database. The receipt acknowledgements are sufficient. You don't need the "job" you mention. Unacknowledged messages are treated as not being sent. Nov 2, 2015 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.