Hello, have you tried the ZMQ_DONTWAIT flag on the send call? Depending on your version of ZeroMQ, it may be ZMQ_NOBLOCK
----- Mail original ----- > De: "Robert Pickering" <[email protected]> > À: "ZeroMQ development list" <[email protected]> > Envoyé: Lundi 14 Septembre 2015 16:56:18 > Objet: [zeromq-dev] PUSH socket blocks when no client is connected > Hi all, > > I'm running into a problem that PUSH sockets always block on send when > no PULL socket is connected. > > First a brief note about what I'm trying to achieve: I'm trying to > distribute notifications from one server to a number of clients. The > scenario looks a lot like sub/pub, but there's an important difference > that means sub/pub is not suitable. The difference is I'd like all > clients to receive all notifications and tolerate a short disconnection > period. When a client crashes the server should queue messages for the > client until the client restarts. If the client is disconnected for too > long then messages can be thrown away. > > With with SUB/PUB sockets, if a crash in the client occurs the > notification received are received by all remaining active clients but > are lost to the client that has crashed. I'm trying to implement this > scenario using PUSH/PULL sockets but running into the problem that send > blocks when no PULL client is connected. > > I know the number of clients in advance, so each client has it's own > PUSH socket on the server. To send a notification I loop over all the > sockets on the server and send the notification. This works well until > one client is disconnected then it's socket starts to block, so no > further notifications can be send. > > I've tried many things to get the PUSH to queue the message instead of > blocking, including setting the socket options: ZMQ_SNDBUF to 1000000, > ZMQ_SNDHWM to 10000 and ZMQ_IMMEDIATE to 1, although from my reading of > the docs none of these should be necessary. > > Is there anyway to get the PUSH socket to queue the messages rather than > block when no client is connected? Or, if what I'm trying is not the > best pattern to implement the scenario described I'd be very interested > to hear ideas on other ways to implement it. > > Many thanks, > Robert > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
