We are running a Node.JS app on Bluemix that uses the mqlight service.
Are the messages really being queued in case there are no receivers? Is it possible for a receiver to fetch messages that were sent before it connected?
Are messages really being queued in case messages are being sent faster than they are handled?
Using the Time-To-Live property of messages, messages can be persisted on the destination topic until a subscriber connects. This will allow you to buffer messages whilst they are no subscribers.
Full details for this property are available here.
Related
Am using sensu server with Elastic cache and have a huge list of clients that they are tiring to send a message but during the keepalive or any notification am using handlers using SNS topic.
But I have differentiated the client but adding Subscriber so that i can identify what is prod and non-prod but notification am not able to split with diff SNS topics using multiple handlers.
When sending messages via Firebase Cloud Messaging, the repsonse from FCM servers tell about the processing of the Request but not whether it was delivered or not to the device.
So, for offline devices how could we know whether message was delivered?
For example,
{"multicast_id":7138524052704576147,"success":1,"failure":0,"canonical_ids":0,"results":[{"message_id":"0:1472139369768700%d42090b5d42090b5"}]}1
the above JSON is a response from FCM server for request with time_to_live:0 and priority:'high' but the situation is that device for which I want to receive the message is offline.
Is there any possible way to detect if the device is offline?
Yes. If you link your FCM API key with Developer Console, you have access to View FCM statistics and issues. In particular:
Using FCM Diagnostics, you can troubleshoot messages sent through FCM. You can look up the message(s) by registration token or message ID.
…
You can look up messages sent through Firebase Cloud Messaging with a registration token or message ID.
The message status returned indicates whether the message was delivered, stored, expired, etc.
Note that this diagnostic tool should only be used if you have a made a recent request. This is what the Developer Console says in the FCM Diagnostics section:
This is not a real-time diagnostic tool, the data shown may be a few minutes out of date, and is only kept for a few days. If you do not see the data that you were expecting, please try again after a short while.
I'm reverse engineering some code that sends a message to an Amazon SQS queue. I know the name of the queue, and can find it in the my AWS console. However, I don't know what is subscribed to the queue. I'd like to see how the message is being processed. Is there an easy way to find that? I can't see anything in the console, or in the CLI... I was hoping for something comparable to rabbitmqctl, which can show you a list of subscribers.
You don't subscribe to an SQS queue. SQS queues have listeners that poll (usually long-poll) the queue for messages.
Anybody anywhere with valid, authorized credentials possessing the permission to receive messages from the can poll it (or not poll it) at any time.
Queues don't have subscribers -- topics, like in SNS -- have subscribers, where messages are broadcast to all subscribers each time a message is published.
There are several Cloudwatch metrics for SQS queues that you can use to determine whether the queue is being polled, but the interactions between listeners and queues is a different model than some other message queue platforms, where listeners to the queue maintain a persistent connection (and can therefore potentially be enumerated). An SQS listener connects, receives any available messages up to the max allowed or requested, disconnects¹, processes the messag(es), then reconnects to delete the messages (otherwise the messages eventually become visible for another listener to receive... or the same listener... SQS has no concept of "who" is listening, because everything works over HTTP which is, of course, stateless.
¹Of course, with HTTP keep-alive, the listener may not technically disconnect the TCP connection to the SQS API endpoint, but there is no state preserved when this happens and SQS has no sense that the listener is "still connected."
Let's say a user accesses a resource and it maps to a handler foo().
In foo() I want to check if the user's session is valid.
For maximum decoupling (and for the sake of the example) I put the provided session ID into a message and push that into the queue VERIFY_SESSION where it is picked up by a subscribed worker.
The worker takes the session ID out of the message, checks the database, etc and then adds some data indicating the session is valid to the message before pushing it to VERIFIED_SESSIONS.
Question:
How do I get the information that the session is valid back into the worker that handles the user's connection?
If I subscribe all frontend workers to the queue VERIFIED_SESSIONS, there is no way of telling which worker will receive it.
All I can think of would be to basically implement RPC on top of the message queue, but that would defeat the purpose of having the queue to begin with.
What is the common pattern here?
When sending messages with SSB we'll initialize conversations by specifying to and from services.
But when reading, all we do is to RECEIVE without specifying services. So how do I make sure that I read messages which are only for service X?
Or have I missed something fundemental?
To RECEIVE for service A, RECEIVE from service A's queue. To RECEIVE from service B, RECEIVE from service B's queue.
You should only place two services on the same queue if the processing is identical and you really do not care about which service does the message belong to. You can even project the service name in the RECEIVE result set so you can know that your message belongs to A or B, if is important in processing. As a general rule there is no way to declare 'RECEIVE messages that meet criteria X and ignore the rest'. The idea is that messages are events that require handling, so you cannot choose what event you look at next.