Reputation: 2695
I currently have a system in which the apps ping each other to check they're still alive. I have 1 client, which sends requests, 1 router which distributes them and 2 workers which do the work and return the results.
If a worker dies, the router works it out and only sends to the other. This gives me time to see whats gone wrong and act accordingly. If the router dies, then the client knows about it. What I would like to know however is if my client works out that the router's died, (which it can do), then it takes any messages being queued up and simply sends them back.
It's a chat app, so somebody will send a message, this will go to the client dealer port. The dealer will suddenly go "waaah the router's dead!" and send the message back along with an error to say the system is currently down. This way if catastrophy hits, users will know that the system is down and stop sending messages until it comes back up.
Is there a way to do this? Am I right in saying that the high water mark knows internally how many messages have currently not been sent, and maybe I could use some function to get all the queued messages back off zero mq?
Many thanks
Upvotes: 0
Views: 191
Reputation: 2695
For those who have a similar thought, I found the best solution was actually to add a timeout on the client side. Cache the last data requests on the users browser and if there hasnt been a reply within a suitable time frame, file an error report.
Failing that, the only other options I could find were to either handle the caching yourself or use a different messaging platform (rabbitmq, activemq). The memory requirements alone bothered me too much to consider these however personally.
Upvotes: 0
Reputation: 13766
Nope, you'll have to handle it in your application. You'll need to keep a copy of the message, if ZMQ pukes and is unable to send it, you can manage that appropriately in your application. Once you have determined it has gone through, then you can discard it.
Upvotes: 1