I am looking into this, let me see what I come up with, and if it's any decent I would be happy to submit a pull request
On Wed, 29 Jul 2015 08:10:57 +0000, Henryk Konsek <hekon...@gmail.com> wrote: > 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 <e...@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 <hekon...@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 <e...@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 > > > > > >
