[zeromq-dev] Issues with large numbers of clients

[Will Moss]

Hi Peter,

I have looked through the internals a bit, but certainly don't understand
them entirely. That said, I don't think it's possible for it to clean up on
disconnect--if it did it would not be providing the abstraction surrounding
client reconnections that it promises. I made a little test program to
prove this to myself: https://gist.github.com/662192fac6fb9d77fc2b

Let me know if I can provide any more assistance with the epoll bug. I'd
love to get it fixed because the behaviour when this occurs is to have the
process cpu spike up to 100% and start processing substantially fewer
requests that it should (resulting in us having to restart the process and
lose data in flight).

Thanks,
Will


On Wed, Jan 23, 2013 at 12:16 PM, Pieter Hintjens <ph at imatix.com> wrote:

> On Wed, Jan 23, 2013 at 8:01 PM, Will Moss <wmoss at bu.mp> wrote:
>
> > I can certainly make a test case for the socket leakage, but as I said
> > before, I thought this was a known issue, so I'm a little confused.
>
> The issue the Guide talks about is application code that tracks peers.
> I've not tested, and it's not documented, how the ROUTER socket
> manages its internal tables. I'd expect the router socket to clean up
> its internal tables when clients disconnect. So if it's not doing
> this, we need a test case.
>
> > I doubt I'm going to be able to come up with a test case that can get a
> > socket into EPOLLERR or EPOLLHUP, but I think it's reasonably easy to see
> > how this can happen from the code.
>
> That may be enough to fix the problem.
>
> -Pieter
> _______________________________________________
> 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/20130125/5dfa1452/attachment.htm>