I am implementing an Apple notification push service and am processing an internal queue.
I would like to know if PushSharp notifications always raise the "NotificationSent" or "NotificationFailed" events (one or the other - at least one of them).
Also if the notification does successfully send, doe the NotificationSent event always fire for each successful notification sent or can there be circumstances where this does not occur even though it sent successfully?
I've been working with PushSharp (latest lib v2.0.4) and all my messages have either triggered NotificationFailed() or NotificationSent(). But this is no guarantee that the messages will reach the end user (device). Apple or Google are sending an ACK that their servers have received the notification successfully (or not) from my push service. Then it's in their hands to send on to the final device.
Furthermore, how are you closing your push services? If you call StopAllServices(true), the service will wait for all ACKS to be received before shutting down. If called as StopAllServices(false) then it shuts down not waiting for acks and therefore the events NotificationFailed() or NotificationSent() will not be triggered.
Hope this helps.
Related
My Google-fu has failed me, Stack Overflow Gods...
I have a very basic bot running on 4 of my servers that handles scheduling and, as long as the bot is online, it works marvelously, but as soon as it goes offline for whatever reason, it stops listening to any of the messages already in the channel and will only listen to newly sent messages.
E.G. Let's say that every time the bot is online is starts a new session and when it goes offline, that session ends. So, if my bot is online for the first time, it's in Session 1 and listens to all messages sent during Session 1, but as soon as it goes offline, Session 1 ends. When it comes back online, it starts Session 2 and stops listening to messages that were sent during Session 1 and only listens to messages that are sent during Session 2.
How can I get the bot to listen to all the messages in one channel? (How can I get it to listen to all messages from all "Sessions")
Thank you kindly
I was building a service that runs on Cloud Run that is triggered by PubSub through EventArc.
'PubSub' guarantees delivery at least one time and it would retry for every acknowledgement deadline. This deadline is set in the queue subscription details.
We could send an acknowledgement back at two points when a service receives a pub-sub request (which is received as a POST request in the service).
At the beginning of the request as soon as the request was received. The service would then continue to process the request at its own pace. However, this article points out that
When an application running on Cloud Run finishes handling a request, the container instance's access to CPU will be disabled or severely limited. Therefore, you should not start background threads or routines that run outside the scope of the request handlers.
So sending a response at the beginning may not be an option
After the request has been processed by the service. So this would mean that, depending on what the service would do, we cannot always predict how long it would take to process the request. Hence we cannot set the Acknowledgement deadline correctly, resulting in PubSub retries and duplicate requests.
So what is the best practice here? Is there a better way to handle this?
Best practice is generally to ack a message once the processing is complete. In addition to the Cloud Run limitation you linked, consider that if the endpoint acked a message immediately upon receipt and then an error occurred in processing it, your application could lose that message.
To minimize duplicates, you can set the ack deadline to an upper bound of the processing time. (If your endpoint ends up processing messages faster than this, the ack deadline won’t rate-limit incoming messages.) If the 600s deadline is not sufficient, you could consider writing the message to some persistent storage and then acking it. Then, a separate worker can asynchronously process the messages from persistent storage.
Since you are concerned that you might not be able to set the correct "Acknowledgement Deadline", you can use modify_ack_deadline() in your code where you can dynamically extend your deadline if the process is still running. You can refer to this document for sample code implementations.
Be wary that the maximum acknowledgement deadline is 600 seconds. Just make sure that your processing in cloud run does not exceed the said limit.
Acknowledgements do not apply to Cloud Run, because acks are for "pull subscriptions" where a process is continuously pulling the Cloud PubSub API.
To get events from PubSub into Cloud Run, you use "push subscriptions" where PubSub makes an HTTP request to Cloud Run, and waits for it to finish.
In this push scenario, PubSub already knows it made you a request (you received the event) so it does not need an acknowledgement about the receipt of the message. However, if your request sends a faulty response code (e.g. http 500) PubSub will make another request to retry (and this is configurable on the Push Subscription itself).
I found this docs: https://cloud.google.com/nodejs/docs/reference/pubsub/0.19.x/v1.SubscriberClient#acknowledge
If a message is acknowledged failed, will it be put back to the message queue and wait for redelivering later? Or this message is lost?
Acknowledgements in Google Cloud Pub/Sub are best effort and the service as a whole has at-least-once delivery of messages. What this means is that if an acknowledgement fails (and even in rare cases, if you get back that an ack succeeded), the messages will be redelivered to a subscriber. A message is only deleted from Pub/Sub if the service successfully receives and processes an ack for the messages messageRetentionDuration passes, which defaults to seven days.
I've looked by I couldn't find out what happens to conversations when one side has an issue and how to handle it. I think I've seen a few times when there was an error in the TargetService and it caused another error to occur.
I have a stored procedure which begins a conversation and sends a RequestMessage to a TargetQueue associated with a TargetService and a contract. It then waits for up to 5 seconds to receive a message with that conversation handle on the InitiatorQueue.
Meantime an application on another server is waiting in a loop to receive messages on the TargetQueue, process them calling yet another system, and sending a ResponseMessage to the InitiatorQueue.
Timeout
Since the stored procedure should be responsive it waits at most 5 seconds because a user is waiting for a response. If the application takes longer than 5 seconds to send a response, it goes ahead and ends the conversation. When the application finally succeeds it will send the response to the InitiatorQueue and end it's side of the conversation.
So what happens to that ResponseMessage in the InitiatorQueue? Does it have to be cleaned up somehow? Since the requestor only ever listens for a response with the same conversation handle, it will never be received. Will it be deleted when the 60 second lifetime I have specified for the dialog expires?
Error
So what if the application has a critical error and crashes (or the server goes down) while there is a message in the TargetQueue? The initiator will close their side of the conversation, and the 60 second lifetime for the dialog will elapse. Will everything be cleaned up?
What if the message has been received from the TargetQueue and the error occurs before a response is sent. Will that dialog remain out there?
Just doing some testing, there doesn't seem to be a way to tell when I receive a message on TargetQueue if the dialog has been closed by the sender yet. This leads to the application processing the RequestMessage and erroring out on the SEND to the InitiatorQueue. Could/Should I attempt a receive on TargetQueue and close the dialog a second time in the stored procedure to clear the queue before I return a timeout error?
I am new to MQTT and I have some questions that I hope you guys could help me with. I'm working on a school project that will require me to utilize the MQTT protocol and the program needs to be written in C. (Just some background info)
Can a MQTT client be both a publisher and a subscriber at the same time? That is, while constantly waiting to receive messages from the broker and perform resulting actions, it is also able to publish messages to a broker when needed to.
My understanding of MQTT is as such: MQTT Publisher --> MQTT Broker --> MQTT Subscriber
What exactly is the Asynchronous mode of MQTT, in idiot terms?
Thanks!
1) Yes, there is no reason a MQTT Client can not be a Published and a Subscriber, this is a normal mode for a client to work in.
2) An Asynchronous MQTT client implementation is one that does not block when carrying out network operations (sending or receiving data). This means that all the network operations take place in the background, a token is returned from any call that would normally block that can be used to check if that operation succeeded later.
1) When you say your mqtt client has subscribed to a particular topic it means that It will keep on listening to that till either it is unsubscribed or the connection is Terminated. When you say your mqtt client is publishing, it publishes the MqttMessage to the Broker and all the clients who are subscribed i.e listening will receive the message. So you just need to keep yourself subscribed and start publishing.
2)Asynchronous mode doesn't block the thread for performing any action. It just acts on the given action and returns a token which can be used to track and wait for the action to get completed. This is opposite to Synchronous mode where the Thread is blocked till the action is completed on reached the timeOut period.
Eg: When you publish in Asynchronous mode, you will be returned a IMqttDeliveryToken which can be used later to verify if the publish action was completed.