tordu avec zmq donnant une erreur étrange

Question

J'utilise twisted avec zmq. voici une vue d'ensemble de l'application:

J'ai deux instances torsadées fonctionnant sur deux systèmes et j'utilise zmq(txZmq) pour le passage de message.

systemA soumet des emplois à traiter par systemB après le travail .and est terminé, il doit en aviser systemA (pour certaines raisons diablotin). donc sur les deux systèmes, j'ai zmq écouter ainsi que d'envoyer des messages en utilisant différents ports. maintenant je reçois erreur: zmq.error.Again: Resource temporarily unavailable il peut être parce que le réacteur sur systemA traite un certain système de données B arrive à envoyer un message de notification (qui fait partie de mon application) à systemA sur lequel zmq écoutait également pour les messages entrants.

donc je changé la partie de traitement sur systemA à un fil torsadé en utilisant callInThread également fil à l'intérieur j'envoie un message à ZMQ mais encore une fois je reçois la même erreur zmq.error.Again: Resource temporarily unavailable

pourquoi est-il si ??? Code est quelque chose comme ceci:

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, je ne sais rien du tout à propos de Twisted, mais

il pourrait être parce que quand le réacteur sur systemA est en train de traiter une systemB de données arrive à envoyer un message de notification (qui fait partie de mon application) à systemA sur lequel zmq était également à l'écoute des messages entrants.

ne semble pas correct. ZeroMQ implémente le modèle de programmation Actor, dans lequel les messages sont mis en file d'attente (sur l'expéditeur, dans le réseau lui-même et au niveau du récepteur) et sont transférés au fur et à mesure que la connectivité le permet. Il n'y a donc aucun rendu implicite dans l'envoi et la réception d'un message dans ZeroMQ. Ainsi, même si SystemA était occupé à faire autre chose au moment où SystemB envoie sa notification, cela ne posera aucun problème.

zmq.Error.Again ressemble à EAGAIN enveloppé joliment pour des raisons Pythonesque. Cela est renvoyé par zmq_send() si un message a été envoyé avec l'indicateur ZMQ_DONTWAIT défini, mais pour une raison ou une autre, le message n'a pas pu être envoyé. Plusieurs raisons peuvent expliquer (mais sans s'y limiter) à:

• Le CONCESSIONNAIRE ZMQ ou prise PUSH entre B et A n'a pas réellement connecté, dans ce cas, vérifiez vos chaînes de connexion, etc.
• B envoie des notifications plus rapide que A peut les consommer. Les tampons sur B, le réseau et A se remplissent graduellement, et une fois plein, il ne peut plus être envoyé. Cependant, cela semble peu probable étant donné que les notifications de B sont en réponse à A envoyant des tâches à A, A définissant le taux de travail, et B ne peut pas (sauf les bogues) envoyer des notifications plus rapidement que A envoie des tâches.

Note générale

ZMQ ne garantit pas la livraison des messages. Un zmq_send réussi signifie simplement qu'un message a été mis en file d'attente pour l'envoi.

Si les conditions (c.-à-d.le socket est connecté et le récepteur appelle réellement zmq_recv) sont corrects le message sera transféré soit entier, ou pas du tout. Rien de partiel. Cela contraste avec, disons, un environnement de processus séquentiels de communication dans lequel un message ne peut être envoyé que si le destinataire est prêt et en attente de réception du message. Ainsi, avec CSP, quand un message est envoyé, vous savez qu'il a été reçu - un rendu. C'est beaucoup plus agréable dans les environnements où l'on doit se soucier de la tolérance aux pannes/récupération/etc