camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ioannis Alexandrakis (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-5719) ZooKeeper route policy should initialize using onInit to elect master
Date Thu, 04 Dec 2014 09:05:12 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14233431#comment-14233431
] 

Ioannis Alexandrakis edited comment on CAMEL-5719 at 12/4/14 9:04 AM:
----------------------------------------------------------------------

I wanted the same thing; having a single instance running from the creation of the camel context.
The way the policy currently works is that it "waits" for the first exchange  to stop the
consumers from processing. It might be useful if the exchange is expendable (e.g. route is
a *file* component or something of the sort). If it is not, (e.g. a *jetty* or an *activemq*
component), it would mean that the +first exchange (if it happens to arrive on a 'secondary'
camel route) would be 'lost'+ and if it hasn't been thought through, it might mean problems
in the application.

The most useful approach would be to not start the route on the onInit phase. However, there
are some inherent problems (for example, the context is not yet fully started between all
those phases and I think you can't mark a route as autoStartup = false in any of the RoutePolicy's
methods, it won't work, and the context is not yet fully initialized). Moreover, the component
itself 'injects' another route (election-route-XXXXXXXX) in the camel context itself, which
makes the things even more complicated.

One way would be to setAutoStartup(false) in the camel context containing the routes. However,
if you have routes that you don't want to be suspended from the beginning, this would create
problems. This would not start the injected election route from the above paragraph too. And
you can't get a callback (apart from the StartupListener interface, I couldn't find anything
else that could help).

h5. In the end, I managed to get the expected behaviour by doing the following:
*1)* Created a new camel context (this could be static, for performance reasons, but I do
not think it has a large overhead), in which I put the election route, just to be easily manageable,
and to distinguish it from the others. This has the downside that you have to manually start/stop
it (however I think it is not a problem, I close it overriding the +doShutdown()+).
*2)* For each route, overrode the +onStart(Route route)+ and check whether the node +isMaster+.
If it is not, stop its consumers (this way, it doesn't get to process anything yet, and we
assume it is 'paused'). We might be able to avoid the step above with the new camel context,
if we make sure that the +onStart(Route route)+ is not run for the election route (because
it would create a deadlock). However, I like the idea of the election route being separate
(in karaf the route was appearing when I was scanning the camel contexts. When it was alone,
it was 'hidden')


So, having those modifications, we get the benefit of having the route without consumers if
it is not a primary node on startup, however on any election change, the consumer(s) will
be started.

I tested it within karaf, and the behaviour was what I expected, single instance of a route
running at all times.
(+the attached patch is from 2.14.1-SNAPSHOT+)

Note: after these checks, I think the +onExchangeBegin(Route route, Exchange exchange)+ does
not need the check the election. However, I did not modify anything there, just for safety.


was (Author: ialex):
I wanted the same thing; having a single instance running from the creation of the camel context.
The way the policy currently works is that it "waits" for the first exchange  to stop the
consumers from processing. It might be useful if the exchange is expendable (e.g. route is
a *file* component or something of the sort). If it is not, (e.g. a *jetty* or an *activemq*
component), it would mean that the +first exchange (if it happens to arrive on a 'secondary'
camel route) would be 'lost'+ and if it hasn't been thought through, it might mean problems
in the application.

The most useful approach would be to not start the route on the onInit phase. However, there
are some inherent problems (for example, the context is not yet fully started between all
those phases and there is no easy way to stop the route while the context is not yet fully
initialized). Moreover, the component itself 'injects' another route (election-route-XXXXXXXX)
in the camel context itself, which makes the things even more complicated.

One way would be to setAutoStartup(false) in the camel context containing the routes. However,
if you have routes that you don't want to be suspended from the beginning, this would create
problems. This would not start the injected election route from the above paragraph too. And,
finally, things get complicated if you try to start/stop routes before the context is fully
started. And you can't get a callback (apart from the StartupListener interface, I couldn't
find anything else that could help).

h5. In the end, I managed to get the expected behaviour by doing the following:
*1)* Created a new camel context (this could be static, for performance reasons, but I do
not think it has a large overhead), in which I put the election route, just to be easily manageable,
and to distinguish it from the others. This has the downside that you have to manually start/stop
it (however I think it is not a problem, I close it overriding the +doShutdown()+).
*2)* For each route, overrode the +onStart(Route route)+ and check whether the node +isMaster+.
If it is not, stop its consumers (this way, it doesn't get to process anything yet, and we
assume it is 'paused'). We might be able to avoid the step above with the new camel context,
if we make sure that the +onStart(Route route)+ is not run for the election route (because
it would create a deadlock). However, I like the idea of the election route being separate
(in karaf the route was appearing when I was scanning the camel contexts. When it was alone,
it was 'hidden')


So, having those modifications, we get the benefit of having the route without consumers if
it is not a primary node on startup, however on any election change, the consumer(s) will
be started.

I tested it within karaf, and the behaviour was what I expected, single instance of a route
running at all times.
(+the attached patch is from 2.14.1-SNAPSHOT+)

Note: after these checks, I think the +onExchangeBegin(Route route, Exchange exchange)+ does
not need the check the election. However, I did not modify anything there, just for safety.

> ZooKeeper route policy should initialize using onInit to elect master
> ---------------------------------------------------------------------
>
>                 Key: CAMEL-5719
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5719
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-zookeeper
>    Affects Versions: 2.10.0
>            Reporter: Claus Ibsen
>             Fix For: Future
>
>         Attachments: zookeeper-election.patch
>
>
> See nabble
> http://camel.465427.n5.nabble.com/Single-instance-of-running-route-in-the-cluster-tp5720846.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message