[zeromq-dev] max PUB/SUB topics

[Bill Torpey]

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 <briantcarcich at gmail.com> wrote:
> 
> On Wed, May 15, 2019 at 8:40 AM Bekritsky, Benjamin via zeromq-dev <zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>> 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 <jamesdillonharvey at gmail.com <mailto:jamesdillonharvey at gmail.com>> 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
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

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