[zeromq-dev] Discussion on ROUTER action

[Yu Dongmin]

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 <somdoron at gmail.com> 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 <miniway at gmail.com> 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 <ph at imatix.com> 작성:
> 
> > 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 <miniway at gmail.com> 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
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121210/c57b7ee9/attachment.htm>