Hello, OK, now an issue seems to be
- Do an application need to distinguish between the target pipe is full and doesn't exist - What would be a desired action when pipe is full ? (Now it silently drops and returns a success) - What is the expected behaviour on ZMQ_ROUTER_MANDATORY when pipe is full or pipe doesn't exist Basically, we must have a way to know the ROUTER failed to send when the target pipe is full. My first assumption ware - An application need to tell them - An application wants the ROUTER to handle the full until the pipe is ready. Another thought was - If an application has to handle the failure (by resending or logging), because a peer can reconnect, knowing the cause might not be meaningless - A thread should not block when one of peer is full. My pull request was based on the second. Application has to deal with the failure whatever the reason is and I have to rewrite all the router-router proxy (device) to add a retry. But I still miss a third option that the ROUTER handle the by returning EAGAIN. :) It could be easier in a situation than adding a retry to every router when an application wants to handle the full. Thanks, Min On Dec 9, 2012, at 7:13 PM, Doron Somech <[email protected]> wrote: > Hi, > > Min i took a look at the code and in case of pipe full or identity doesn't > exist you are returning the same error, right? i think it better in case the > pipe is full to return eagain, then the SocketBase send method will continue > to try sending the message until timeout or message is sent. also at the > application code i can see a different handling of pipe is full and pipe > doesn't exist. > > Doron > > What do you think? > > On Fri, Dec 7, 2012 at 3:24 PM, Min <[email protected]> wrote: > OK, > > I'm going to send a pull request as the ZMQ_ROUTER_MNDATORY covers the > counterpart full case also. > > Thanks > Min > > 2012. 12. 7. 오후 9:24 Pieter Hintjens <[email protected]> 작성: > > > Hi Min, > > > > I think you could extend ZMQ_ROUTER_MANDATORY to this. Mandatory means > > the message must be deliverable, or you get an error. > > > > -Pieter > > > > On Thu, Dec 6, 2012 at 4:36 AM, Yu Dongmin <[email protected]> wrote: > >> Hello, > >> > >> As we all know, ROUTER drop messages when 1) a counter part doesn't exist > >> and 2 ) a counter part is full. > >> > >> In case of 1) we can catch the case by setting ZMQ_ROUTER_MANDATORY. But > >> in case of 2) ROUTER drop message silently and the send returns 0. > >> > >> > >> Server side ROUTER-DEALER pattern including the proxy (a.k.a device) is > >> hard to use as I need another treatment at client side. > >> > >> To make a client simple and avoid the second case of silent dropping, I > >> have to increase the HWM or unlimited but it could blow memory. > >> > >> > >> We might need an another option to detect second case. By detecting the > >> case, ROUTER user can decide whether he drop it silently (default action), > >> resend it or wait the counter part is ready. > >> > >> > >> My idea is (please ignore option names, they are just examples) in the > >> case of 2) > >> > >> if ZMQ_ROUTER_WAIT set router.xsend returns -1 with EAGAIN so system can > >> wait the counter part is ready > >> Otherwise returns -1 as user can do his treatment. > >> > >> Thanks > >> Min > >> _______________________________________________ > >> 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 > _______________________________________________ > 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
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
