camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henryk Konsek <hekon...@gmail.com>
Subject Re: Possible bug in JGroupsFilters.dropNonCoordinatorViews?
Date Wed, 29 Jul 2015 08:10:57 GMT
Hi Ed,

Oh, you are thinking about the case when only network is down, not the
whole node. That would definitely make sense.

Do you plan to work on such feature? Pull request with such functionality
will be highly appreciated :) .

Cheers!

wt., 28.07.2015 o 16:52 użytkownik Ed Welch <ed@edjusted.com> napisał:

> Hi Henryk!
>
> Follow up question, do you think there is a use case for shutting down a
> running route?
>
> Say the coordinator in the cluster gets disconnected (unplug a network
> cable or something), the remaining members elect a new coordinator and he
> starts his route.
>
> The first node then reconnects, would it make sense for him to look at the
> incoming View and if he's no longer the coordinator, to call shutdown on
> the route?
>
> On Tue, 28 Jul 2015 14:15:48 +0000, Henryk Konsek <hekonsek@gmail.com>
> wrote:
>
> > Hi Ed,
> >
> > This is bug indeed. I have just fixed it in CAMEL-9029 [1]. The bug was
> not
> > detected so far, because channels used for cluster configuration usually
> > don't exchange non-view messages.
> >
> > Thanks for catching this! Cheers!
> >
> > [1] https://issues.apache.org/jira/browse/CAMEL-9029
> >
> > wt., 28.07.2015 o 12:45 użytkownik Ed Welch <ed@edjusted.com> napisał:
> >
> > > Was looking at using the jgroups component to coordinate some
> master/slave
> > > routes, and was digging into the source for the example to see how it
> works.
> > >
> > > Everything seems straight forward to me with one issue:  the
> > > dropNonCoordinatorViews method in JGroupsFilters looks like it may
> have a
> > > bug:
> > >
> > > public static Predicate dropNonCoordinatorViews() {
> > >         return new Predicate() {
> > >             public boolean matches(Exchange exchange) {
> > >                 Object body = exchange.getIn().getBody();
> > >                 JGroupsFilters.LOG.debug("Filtering message {}.",
> body);
> > >                 if(body instanceof View) {
> > >                     View view = (View)body;
> > >                     Address coordinatorNodeAddress =
> > > (Address)view.getMembers().get(0);
> > >                     Address channelAddress =
> > > (Address)exchange.getIn().getHeader("JGROUPS_CHANNEL_ADDRESS",
> > > Address.class);
> > >                     JGroupsFilters.LOG.debug("Comparing endpoint
> channel
> > > address {} against the coordinator node address {}.", channelAddress,
> > > coordinatorNodeAddress);
> > >                     return
> channelAddress.equals(coordinatorNodeAddress);
> > >                 } else {
> > >                     JGroupsFilters.LOG.debug("Body {} is not an
> instance
> > > of org.jgroups.View . Skipping filter.", body);
> > >                     return true;
> > >                 }
> > >             }
> > >         };
> > >     }
> > >
> > >
> > > So if the message from the jgroups component is a View, and the
> > > coordinator address matches this channel address, return true,
> indicating
> > > we are the coordinator, and we can start the route.
> > >
> > > However, if the message which was received on the Channel was not a
> View
> > > object, this method returns true.
> > >
> > > If this is used according to the example:
> > >
> > > from("jgroups:clusterName?enableViewMessages=true").
> > >   filter(dropNonCoordinatorViews()).
> > >   threads().delay(delayIfContextNotStarted(SECONDS.toMillis(5))).
> > >   to("controlbus:route?routeId=masterRoute&action=start&async=true");
> > >
> > > Wouldn't that mean any non View type message would cause the route to
> > > start??
> > >
> > > Shouldn't that default case for non View type messages return false?
> > >
> > > Thanks,
> > > Ed
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message