I understand that Erlang process message is sync.
When I do
Pid ! message
the sending message thread return right now
the sending message thread will confirm the message has put in the Pid's message queue and then return.
Which choice will the sending message thread do ?
I believe your understanding might be wrong. Erlang message passing is asynchronous.
For example have a look here.
To answer your question then the option number 1 is what's happening here.
In Erlang, message passing is asynchronous. The sender never blocks. Message delivery is not guaranteed. Caveats:
If messaging a local process, then in practice, messages always arrive and do so very quickly.
If messaging a remote process, then messages will be queued for sending. But due to the nature of TCP and distribution, it is not guaranteed that the message will be transferred and processed by the other party.
I think
the sending message thread return right now.
is right.
because Pid ! message just put the message into the message queue of process Pid. the process Pid will use receive to check its message queue. this is nothing with the sending process.
Related
We have mqtt producer and consumer.
MQTT producer is at client level.
When we push message to producer, if the device is switched on, then it will receive the message.
If the device is switched off, then it wont receive the message until it turned on.
We need to know, when message sent to MQTT in server, if server is switched off, then we need to know the status as, it is queued or not received by server.
Based on it, we will send message for the user as, Please turn on device to do specific action.
Is there any better approach to know the status in MQTT to find is message is delivered or failed or queued to know server is active or not.
There is no end to end delivery notification in the MQTT protocol. Part of the pub/sub paradigm is that the publisher should be decoupled from the subscriber, there can be anywhere from 0 to many subscribers to a given topic.
There are 2 approaches to how to potentially work round this.
Have the subscriber respond on a separate topic to acknowledge that it has received the message. You will need to include a unique identifier in the message payload so it can be used in the response message.
You can use the Last Will and Testament feature of MQTT to have the subscriber maintain it's current status. When it starts it publishes a retained message to a known topic, e.g. publishes true to consumer/12345/status and sets a LWT to publish false if the device goes offline unexpectedly. It should also publish false if it cleanly shuts down. That way the publisher can check the status of the subscriber before deciding to publish the message.
I don't know which broker you are using. But in EMQ X MQTT broker, when QoS > 1, the message terminated delivered or ack broker will notify the server
The plugin: emqx-web-hook
We had some sort of bug that queued up the same message thousands of times, each of them is undelivered because of the spam carrier restrictions, because it was a not real number or something.
We've looked around their docs and stack overflow but can't find anything that looks relevant.
It seems like Twilio keeps trying though - over and over - so it's send out thousands of the same message and keeps queueing them. Or at the very least
How can we clear our whole SMS message queue? We're happy if we never send it again, as nothing in there is mission critical.
The best approach is a ticket to Twilio support via the Twilio Console or help#twilio.com as a P1 (with you Account SID), indicating you have an out of control process queuing up thousands of SMS messages.
They will ask that you fix the process and fail the messages in queue.
Here is our scenario:
We are publishing messages to a topic, and have a queue subscribed to that topic. We have several node.js consumers connected to that queue to process incoming messages, via the solclient package.
What we want to do is process the incoming messages, and after successfully processing the message, acknowledge the message so that it is removed from the queue. The challenge we're having is how to deal with error conditions. We are trying to figure out how to flag to the broker that the message failed to be processed? The expectation would be that the broker would then attempt to send to a consumer again, and once max redeliveries is hit, it moves to the DMQ.
I don't believe there's a way in Solace for a consumer to "NACK" a received message to signal an error in processing. I believe your option would be to unbind from the queue (i.e. disconnect() the Flow object, or MessageConsumer in the Node.js API) which will place allow any unacknowledged messages back on the queue and available for redelivery, and then rebind to the queue.
Alternatively, if you do your processing in the message received callback method, you could throw an exception in there, and that should (?) accomplish the same thing. But probably a lot less graceful.
https://docs.solace.com/Solace-PubSub-Messaging-APIs/Developer-Guide/Creating-Flows.htm
https://docs.solace.com/API-Developer-Online-Ref-Documentation/js/solace.MessageConsumer.html#disconnect
We have more than 100k retained messages for this topic 'devices/access_control/inout_status/by_project/#'. After subscribing, we are receiving around 8k-10k messages and then it disconnects with error 'Broken pipe' and after reconnecting, we are receiving the same 10k messages again. How can I solve this problem?
The message delivery is working as intended, you will always get the last retained message for a given topic when you subscribe to that topic.
You are subscribing to a wildcard topic, if you have +10k subtopics under that branch of the topic tree then these messages will always be delivered when you reconnect.
As to why it's dropping the connection with a Broken pipe error, this is probably because you can't process that many messages quickly enough and are flooding the receiver to the point where it can't even drive the low level TCP stack.
I am using MQTT with qos 1 which means messages may be sent to client more than once? How can i prevent client from handle same messages twice?
The only way to know for sure if you have received the message twice is to include an ID in the message payload and maintain a list of processed messages in the client.
The PAHO API includes a isDuplicate() (Javascript version) method on received messages, but this is only an indication that the message may be a duplicate, because the original message may never have arrived.