CODEWITHSUNDEEP
messagingibm-cloudmq
ibmamnt
ibmamnt

Reputation: 129

What is best practice to get notification of MQ Light process complete to web browser?

I'm reading tutorial of worker offload pattern of MQlight. This is suitable for my solution under development.

https://developer.ibm.com/messaging/mq-light/docs/worker-offload-tutorial/

In this tutorial, Exmple2 knows some processes have been completed. Example2 send message to MQlight. And then these worker process handles DB query, and update SNS. However, these process result are not notified to web client.

I wonder what's the possible solution for this in case of Bluemix MQLight service (this service is not visible to Web client). I was thinking to utilize socket.io (or simply websocket) for the process complete message. But this solution has problem in sharing web client information between worker processes. I appreciate if you could share some best practices of process complete message notification to web client.

Thanks !

Upvotes: 1

Views: 313

Answers (1)

Matthew Whitehead
Matthew Whitehead

Reputation: 401

In that blog article it is assumed that the response comes back to the user via some out-of-band mechanism - for example an email to the customer telling them their job is complete.

Request/reply with MQ Light is at the moment limited to using a unique subscription topic pattern for each request/reply flow. This could be by adding a unique identifier in the request message as a property, creating a (probably durable) subscription to a topic pattern that includes the identifier, and having worker processes send their replies to the same topic string. MQ Light doesn't currently offer message selection by properties such as correlation ID.

Returning to your question about doing request/reply to and from a webpage, this isn't really an MQ Light-specific question. Typically you do not want to hold up a servlet thread waiting for a synchronous response from the application processing the request. After all the application could be handling many other requests or even temporarily down while maintenance is applied. Hence why we tend to talk about synchronous request followed by out-of-band reply.

You could implement a system that sends the response back to the browser rather than email/SMS. However what you would likely want to do is submit the request from the browser, let that return as soon as the request has been sent, and then make subsequent AJAX background requests to periodically check for a response on a durable subscription. For example:

  1. When the user submits the HTTP web request, start by creating a durable MQ Light subscription (to make sure the response isn't lost if it's sent back immediately after the request) with a topic string containing an identifier unique to this request
  2. Then publish an MQ Light message containing the request, with a message property containing an same identifier. Then return an HTTP response to the browser.
  3. Have an AJAX HTTP call periodically make requests to another servlet, which in turn resumes the durable subscription, waits a short period for a response message, and returns the contents of the message (if there is one) in the AJAX HTTP response.

While the above would theoretically work, it doesn't scale particularly well and you might well be better off replacing step 3 with an AJAX HTTP call to a database that the MQ Light worker process updates when the job is complete. That scales a lot better.

Upvotes: 2

Related Questions