Pieter, Thanks for confirming the API contract. It turns out that there was no problem in the zloop. I was using java.util.concurrentq's size() function to see if I have any workers available and if not I would remove the poller. The "bug" was in this API, it is "weakly consistent" according to its documentation. I replaced it with a regular queue (I had already removed other threads, so did not need concurrency) and the code started to behave correctly then.
On Sun, Mar 23, 2014 at 1:33 PM, Pieter Hintjens <[email protected]> wrote: > Normally they won't get delivered to your handler after removing the > poller. > > Can you make a reproducible test case and then debug what's happening > in zloop, yourself? > > On Sun, Mar 23, 2014 at 7:47 PM, Mohit Jaggi <[email protected]> wrote: > > Hi Folks, > > I am wondering if removing a poller from a zloop works > "instantaneously". I > > suspect I am getting a message on frontend after calling (using JZMQ > > binding) > > > > loop.removePoller(new PollItem(frontend, 0)); > > > > Is it possible that some messages are in frontend queue when I remove it > > from loop and they get "delivered" to my handler later? My code is based > on > > the load balancing pattern in Zguide which assumes that this never > happens. > > > > Mohit. > > > > > > _______________________________________________ > > 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
