[zeromq-dev] Not receiving unsubscription messages in XPUB socket with ZMQ_XPUB_VERBOSE when using a proxy

Ricardo Catalinas Jiménez jimenezrick at gmail.com
Tue Jul 21 15:52:36 CEST 2015


Good point Brian. Yeah, I see that all the existing flags controlling
the behavior of ZMQ are boolean. In that case I'll add a new flag,
something like:

ZMQ_XPUB_VERBOSE_UNSUBSCRIBE

Sounds good, I'll submit soon a PR and let continue the discussion in
there.

Thanks Brian,

On Tue, Jul 21, 2015 at 09:32:01AM -0400, Brian Knox wrote:
> Do we have any other cases where a flag accepts more than one value?  As
> far as I know, we don't, and in that case it would be my preference to use
> a new flag than to have "modes" for a flag other than on and off.  I
> certainly don't speak for everyone though, and according to our own
> development method I shouldn't be a gate keeper if your PR solves a problem
> unless your PR breaks compatibility / tests or doesn't follow the style
> guidelines.
> 
> Sometimes the best way to find out what opinions are out there is to submit
> the PR, which will either generate discussion or be accepted - after which
> if people have issue with the implementation, they'll submit a follow up PR.
> 
> Cheers,
> Brian
> 
> On Tue, Jul 21, 2015 at 9:11 AM, Ricardo Catalinas Jiménez <
> jimenezrick at gmail.com> wrote:
> 
> > OK, this is my definitive proposed solution, which is a bit simpler and
> > should keep everyone happy. If nobody sees an obstacle here, I'll
> > prepare soon a pull request with this changes:
> >
> > 1. As I described before, don't filter repeated unsubscribe messages in
> >    XSUB. This shouldn't break any API contract.
> >
> > 2. Instead of adding a new flag, add a new accepted value by the already
> >    existing ZMQ_XPUB_VERBOSE, so from now on, apart from accepting 0 and
> >    1, this flag will also accept 2, making unsubscribe messages algo
> >    verbose (no filtering). This is a small incremental change to the API
> >    that doesn't break anything. This new value should be used always in
> >    proxies and optionally it can be use in applications that want this
> >    behavior.
> >
> > Hope this sounds more sensible.
> >
> > On Tue, Jul 21, 2015 at 08:02:54AM -0400, Brian Knox wrote:
> > > Ricardo - if you are lucky, there might be a loophole here for you to
> > > exploit with a little lawyering.
> > >
> > > "This is my preferred solution although it could break applications
> > > that subscribe multiple times to the same topic and expect to stop
> > > receiving messages only when they unsubscribe the same number of
> > > times.  Although I'm not aware that this behavior is documented
> > > which could mean it isn't really a problem."
> > >
> > > Do you know if there is a specific test case for this behavior?  If your
> > > change changes this behavior but does not break the test suite, I believe
> > > it might be accepted.  One of the guiding principals for ZeroMQ
> > development
> > > is, paraphrased, "if you liked it should have put a test around it".  "A
> > > breaking change" is usually interpreted to mean "it breaks the tests"
> > (note
> > > it's the wording Pieter used in his response).  If this behavior is not
> > > documented and it is not tested you should be in good shape, as far as I
> > > know.
> > >
> > > Cheers,
> > > Brian
> > >
> > >
> > > On Tue, Jul 21, 2015 at 6:47 AM, Ricardo Catalinas Jiménez <
> > > jimenezrick at gmail.com> wrote:
> > >
> > > > Correction, I meant XSUB in point 1.
> > > >
> > > > On Tue, Jul 21, 2015 at 11:36:28AM +0100, Ricardo Catalinas Jiménez
> > wrote:
> > > > > [...]
> > > > >
> > > > > 1. Don't filter repeated unsubscribe messages in *XSUB*...
> > > > >
> > > > > [...]
> > > >
> > > >
> > > > /Ricardo
> > > > _______________________________________________
> > > > zeromq-dev mailing list
> > > > zeromq-dev at lists.zeromq.org
> > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > > >
> >
> >
> > /Ricardo
> >


/Ricardo



More information about the zeromq-dev mailing list