[zeromq-dev] zyre question

[Kalyan Bade]

Thanks Pieter.. Please see inline..

On Tue, Jun 30, 2015 at 2:56 AM, Pieter Hintjens <ph at imatix.com> wrote:

> SHOUT will go to all nodes in a given group. Joining a group takes a
> non-zero time.
>
> Isn't the current node need to know who are all part of the multicast
group in order for SHOUT to be reliably transferred to all members? And I
am guessing that this might take some time? We put a sleep of 1 second
after zyre_join() so that it will know of all the nodes that are part of
multicast group.


> You can check this is the issue by doing a sleep before t3. The issue
> will (presumably) go away then.
>

We did play around with different sleep values just before sending the
SHOUT. It has become less prevalent with higher sleep values. But, I was
looking for a deterministic solution as we are seeing the issue rarely with
a sleep as high as 10 seconds


> You can also trace the shout/join messages.
>
> There is no concept of "ready" in a distributed system like Zyre as
> nodes can come and go at any point.
>
> I'm reading your original email again. It could be you're just missing
> a step in one of the threads. Remember the gossip network is separate
> from the Zyre network, except that Zyre wraps the gossip API. Could
> you make a minimal test case showing your problem?
>
>
I will try to get a test case for this soon.

Btw, is gossip network not mandatory for forming the zyre mesh network?

Thanks,
Kalyan



> -Pieter
>
> On Tue, Jun 30, 2015 at 2:53 AM, Kalyan Bade <kalyanbade at gmail.com> wrote:
> > Hi Pieter,
> >
> > Thanks for the answer. I think I didn't explain the issue properly. We
> had
> > this design, but somehow some "shout" messages are lost. Can you please
> help
> > if there is a issue in this approach or am I missing something basic
> here?
> >
> > At time t1 -- Thread 1 starts -- does the following -- zyre_new(),
> > gossip_bind(well-known-inproc-endpoint), zyre_start(),
> > zyre_join(well-known-group)
> > At time t2  -- Thread 2..n starts -- zyre_new(),
> > gossip_connect(well-known-inproc-endpoint), zyre_start,
> > zyre_join(well-known-group)
> >
> > At time t3 -- Thread x sends a "shout" to the multicast group, but it is
> not
> > received by thread 1. This is intermittent though.
> >
> > Are the sequence of steps correct? If the zyre network is not ready at
> t3,
> > is there a trigger so that we can query for the info that is lost.
> >
> > Thanks,
> > Kalyan
> >
> > On Wed, Jun 24, 2015 at 11:52 PM, Pieter Hintjens <ph at imatix.com> wrote:
> >>
> >> This is a catch-22, you are trying to bootstrap the gossip network
> >> using zyre which needs the gossip network to start...
> >>
> >> You should bind a fixed inproc endpoint, and use that to kick off the
> >> gossip discovery.
> >>
> >> On Thu, Jun 25, 2015 at 1:59 AM, Kalyan Bade <kalyanbade at gmail.com>
> wrote:
> >> > Howdy folks,
> >> >
> >> > We recently started using zyre for our inter-thread communications
> >> > (where
> >> > threads come and go and are discovered through zyre using inproc
> comm).
> >> > I
> >> > have a requirement where I need to know when a particular thread joins
> >> > the
> >> > global chat group. I was using the JOIN message and the sender-id from
> >> > the
> >> > message to determine this. But, I don't see this message coming to the
> >> > thread which does the gossip-bind. Is this expected? Is there any
> other
> >> > way
> >> > for the gossip-bind thread to get this JOIN message?
> >> >
> >> > Thanks in advance..
> >> > - Kalyan
> >> >
> >> > _______________________________________________
> >> > zeromq-dev mailing list
> >> > zeromq-dev at lists.zeromq.org
> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150630/d00d4dc0/attachment.htm>