Re: [tipc-discussion] Subscribing for "all" service changes?

[Jon M. <jon...@er...>]

We are routinely testing with 5000 subscriptions, and it works just fine.
So, a few hundreds should be no problem.

///jon


> -----Original Message-----
> From: Peter Fröhlich <pet...@gm...>
> Sent: 26-Apr-19 05:39
> To: Jon Maloy <jon...@er...>
> Cc: tip...@li...
> Subject: Re: [tipc-discussion] Subscribing for "all" service changes?
> 
> I expressed myself unclearly in that second email, sorry for that.
> What I am looking for is "subscribe to changes in the service binding table /
> name table" which is probably some kind of "meta subscription"
> compared to the existing ones that fire when a specific service type comes or
> goes. The goal is to avoid having to subscribe to lots and lots of service types
> explicitly just in order to produce a log of the cluster state over time. (That
> said, I have not noticed any problems with subscribing to hundreds of service
> types, so maybe it's fine to just do that instead.)
> 
> On Thu, Apr 25, 2019 at 2:31 PM Jon Maloy <jon...@er...>
> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Peter Fröhlich <pet...@gm...>
> > > Sent: 25-Apr-19 08:17
> > > To: Jon Maloy <jon...@er...>
> > > Cc: tip...@li...
> > > Subject: Re: [tipc-discussion] Subscribing for "all" service changes?
> > >
> > > On Thu, Apr 25, 2019 at 12:58 PM Jon Maloy <jon...@er...>
> > > wrote:
> > > > No, we don't have any wildcard type for the service type itself,
> > > > only for
> > > changes for a given service type.
> > > > I honestly have never thought about that, nor had any requirements
> for it.
> > > > Bu I 'll give it a thought.
> > >
> > > Thank you! I don't know if it's an undue overhead to support a
> > > wildcard, but if it's straightforward to add it would certainly be
> > > convenient. As of right now we just have a few services so I can add
> > > the IDs manually to configure logging. But as we add more services
> > > it'll get easier and easier to forget to keep that in sync. Also it
> > > seems that for links and nodes I already get the desired behavior,
> > > but maybe there's something about the implementation that makes this
> easier for those two than for all services.
> >
> > Link and node subscriptions are just another two service types, and behave
> exactly like the rest.
> > So, I don't understand your comment. Have I misunderstood your
> question?
> >
> > ///jon
> >
> 
> 
> --
> Peter H. Fröhlich | Senior Code Monkey | https://phf.github.io/