扭曲与zmq给奇怪的错误

Question

i am using twisted with zmq . here is an overview of application :

i have two twisted instances running on two systems and i am using zmq(txZmq) for message passing.

systemA submits some jobs to be processed by systemB .and after job is finished it has to notify systemA (for some imp reasons). so on both systems i am having zmq listen as well as send messages using different ports. now i am getting error : zmq.error.Again: Resource temporarily unavailable it might be because when the reactor on systemA is processing some data systemB happens to send a notification message(which is part of my application) to systemA on which zmq was also listening for incoming messages.

so i changed the processing part on systemA to a twisted thread using callInThread also inside thread i am sending message to zmq but again i am getting the same error zmq.error.Again: Resource temporarily unavailable

why is it so??? code is something like this:

def send_remote_job():
    # do some computation like fetch from db and process then send
    send_socket.push(dumps(job_data))


recieve_socket.onPull = listen_for_notifiction()
reactor.callInThread(send_remote_job)
reactor.run()

Answer 1

Hmmm, I don't know anything at all about Twisted, but

it might be because when the reactor on systemA is processing some data systemB happens to send a notification message(which is part of my application) to systemA on which zmq was also listening for incoming messages.

doesn't sound right. ZeroMQ implements the Actor model of programming, in which messages get queued up (on the sender, in the network itself, and at the receiver) and are transferred as and when connectivity permits. Thus there is no rendevous implicit in sending and recieving a message in ZeroMQ. So, even if SystemA were busy doing something else at the point when SystemB sends its notification, that will not cause any problems.

zmq.Error.Again sounds like EAGAIN wrapped up nicely for Pythonesque reasons. This is returned by zmq_send() if a message were sent with the ZMQ_DONTWAIT flag set but, for some reason or other, the message could not be sent. Possible reasons include (but are not limited) to:

• The zmq DEALER or PUSH socket between B and A has not actually connected, in which case check your connection strings, etc.
• B is sending notifications quicker than A can consume them. The buffers on B, the network, and A gradually fill up, and once full no more can be sent. However, this seems unlikely given that B's notifications are in response to A sending jobs to A, A is setting the work rate, and B can't (barring bugs) be sending notifications quicker than A sends jobs.

General Note

ZMQ doesn't guarantee message delivery. A successful zmq_send merely means that a message has been queued for sending.

If the conditions (ie the socket is connected and receiver is actually calling zmq_recv) are correct the message will get transferred either whole, or not at all. Nothing partial.

This is in contrast to, say, a Communicating Sequential Processes environment where a message cannot be sent unless the recipient is ready and waiting to receive the message. Thus with CSP, when a message is sent you know that it was received - a rendevous. This is much nicer in environments where one has to worry about fault tolerance / recovery / etc.