Min, I think it's accurate to return EAGAIN when the pipe is full, as compared to EHOSTUNREACH when the identity is unknown, and both triggered by the same ZMQ_ROUTER_MANDATORY option.
-Pieter On Sun, Dec 9, 2012 at 10:22 PM, Yu Dongmin <[email protected]> wrote: > 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 > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
