On Dec 28, 2013, at 17:26, Michael Powell <[email protected]> wrote:
> On Sat, Dec 28, 2013 at 11:05 AM, Daniel Krikun <[email protected]> wrote: >> What I wanted to say is that while patterns do simplify development, they >> have there peculiarities, in the example above, i'm doing non-blocking >> receive with REQ/REP which looks benign, but in fact it isn't because if the >> message is not obtained, i cannot send(). > > I don't know your code, but it sounds like a bug worst case, possibly > a feature request best case. You would likely need to report it, > probably clarify what you mean by "if the 'message' is not obtained", > what it is you mean by "I cannot send". This is a quite clear case and well documented on the book and patterns. Peer A sends a message. Something wrong happens with peer B that doesn’t receive the message, or doesn’t reply, or replies but the message never gets back to A. Peer A is dead locked. Peer A needs to disconnect and reconnect. Now if peer A was for whatever reason doing a bind, it would need to fully kill the socket and create a new one. I think simple answer is to never use REP/REQ but instead use DEALER/ROUTER combinations ;) (/me ducks)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
