I would be curious what errno was returned with the failing subscribe call. If EAGAIN, that would at least provide a clue to what was happening. If not, then this should perhaps be raised as an issue so it will get fixed.
> On May 15, 2019, at 1:03 PM, Brian T. Carcich <[email protected]> wrote: > > On Wed, May 15, 2019 at 8:40 AM Bekritsky, Benjamin via zeromq-dev > <[email protected] <mailto:[email protected]>> wrote: > Turns out Justin’s original suggestion to “to set SNDHWM=0 on the SUB socket > and RCVHWM=0 on the PUB socket” resolves the issue. In particular on the SUB > socket. I had mistakenly set the RCVHWM for the SUB socket. > > > > On Wed, May 15, 2019 at 6:23 AM James Harvey <[email protected] > <mailto:[email protected]>> wrote: > [...] > 1. subscriptions make it through to the publisher, this is where the > filtering happens (apart from pgm/mcast transport) > > > Thank you/aHA/Eureka/the light just came on: each setsockopt/ZMQ_SUBSCRIBE > by the subscriber **SeNDs** a message **to** the publisher, which is why the > subscriber needs to set SNDHWM to 0 (I suppose anything over 65535 woould > work for 16-bit topics). > > I updated my example code > <https://github.com/drbitboy/test_0mq_subscribe_limit>, and it now works as > expected. > > > > Philosophical sidebar: why does it seem that we always end up in the > internals? Stated another way, why doesn't the library just work all the > time for every case (Although if it did, wouldn't many of us be out of a > job;-)? > > #1 I am not saying anything against 0MQ; on the contrary, I think it's > amazing. > > I guess the answer is the Pareto Principle (80/20), i.e. that any single > library cannot handle all edge cases with its default settings, so we spend > 80% of our time, digging into the internals, for the 20% that are edge cases. > > For example, the default HWMs of 1000 are not unreasonable; they work fine > until a case like Benjy's comes along, Then, to solve his problem we needed > those (Justin, James) who understand the internals to provide the answer. > Maybe the default HWM should be zero (i.e. infinite; damn the torpedoes, full > speed ahead!;-), and let developers who need finite HWMs set them up > themselves*. Then we'd be fine (until the next edge case;-). > > * sort of like how I got into the habit of putting [IMPLICITNONE] at the > start of every FORTRAN module. > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
