I have a queue of messages that must be displayed to the user every two minutes, one at a time.
Does Pusher have a cron feature?
An example of the desired behavior:
00:00 – User_A sends Message_A and it is enqueued. Once the queue is empty, Message_A is delivered immediately.
00:30 - User_B sends Message_B and it is enqueued.
02:00 - ???? checks the queue and uses Push (or other websocket service) to deliver Message_B
I need the ???? piece.
No, Pusher doesn't offer a cron feature.
But, it would be easy to use a service like iron.io and then hit your own endpoint every two minutes and from that endpoint publish to Pusher.
See:
IronMQ Push Queues
Add Messages to a Queue docs - specifically the 'delay'. This means you can define when you want the message to be queued and effectively published.
Related
I have a requirement where I want to get some kind of notification while the message retention period is over and the message is about to be discarded from the MQTT topic.
So the actual requirement is, we have Bluetooth bands, which are send their presence through a centralized agent and an MQTT broker. Now we got a requirement where we need to upgrade the band firmware. For doing so, we will send a message to the topic with a message and a specific retention period. Infra will receive the message notification and look for the band. If the band is found then it's ok otherwise it will wait for new bands to be available. Once the retention period is over, in some cases we have to retry, so to implement the retry mechanism, I wanted to receive the notification from the MQTT broker if a message retention period is over.
Please help me if this is even possible into MQTT?
The broker won't tell you when it drops messages, but since you know when you sent the message and what expiry time you set there is nothing to stop you implementing this yourself.
Is there any way for a mqtt client to know when his queue was processed and he is "up-to-date" again?
I want to prevent editing of certain elements in the frontend until I am sure that I received all queued changes after a reconnect.
Is that possible?
No, queued messages are not flagged in any way, but they will all be delivered as soon as the client connects.
You could just set a flag when connecting to just stop all UI updates for a period of time to allow messages to arrive and then update with the last data.
Is there a best practice for publishing scheduled/delayed messages with MQTT, for example, using Mosquitto or HiveMQ brokers?
The use case is: Tell a subscriber to perform some maintenance in 15 minutes.
Optimally, the use case would be then solved by publishing the message "perform maintenance now please", and mark the message with "deliver no sooner than 15 minutes from now".
While I wouldn't recommend this to do in any scenario with high throughput, at least with HiveMQ you can do the following:
Implement a OnPublishReceivedCallback.
Schedule a Runnable that uses the PublishService to some kind of shared ScheduledExecutorService. The Runnable re-publishes the publish via the PublishService
The OnPublishReceivedCallback needs to throw away the original publish by throwing an OnPublishReceivedException (use false as constructor parameter so you don't disconnect the publishing client)
No, messages are delivered immediately for all connected clients subscribed to a topic and at reconnection for disconnected clients with persistent subscriptions.
If you want to do delayed messages you will have to implement your own store and forward mechanism before they are published to the broker.
It appears that we aren't getting all AnyOfferChanged notifications on an Amazon SQS. Many are arriving in the queue, but a manual analysis is showing that many are also just going missing.
Is there any way to query MWS to see a list of notifications or even a simple count for the day?
Any common causes for losing MWS subscription notifications sent to SQS?
I don't believe there is a way to query the SQS system. They are just messages in a queue and you read them, process them, and then delete them. We have been using the AnyOfferChanged notifications for about a year and just have to trust that they work. If you're sure that the criteria is met (a product you sell, and a price changes in the top 20 offers, new or used) and there is not message in the queue for it, the I would open a ticket with Seller Central. We have seen that it is near-real time that an SQS notification arrives for one of our product price changes.
To get a count for the day, you'd just have to read messages from your queue starting at a certain point, add +1 to a count variable for each message, delete them from the queue, and then look at the counter after 24 hours. Best I can think of.
So we have a messenger ( I know we should just switch to Xmpp, but no time right now) - problem being if a user sends say 20 messages rapid fire there is more than a good chance of them storing ALLLLL out of order.Is there any way to ensure the requests are sent in order without blocking the user from sending at the pace they want to send?
You can create a queue of NSURLRequest. When the user fires a message, this message is added to the queue and the oldest message of the queue is sent. When the completion blocks (success or failure) are called, send the new oldest message, and so on...
Just be careful to have only one process which send messages.
You can also take a look to NSOperation and NSOperationQueue.