camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <ioca...@gmail.com>
Subject Re: How to make your camel routes highly available when only one may be active at a time
Date Sat, 12 Nov 2011 12:42:34 GMT
Hi Chris,

Actually Hazelcast provides a distributed lock implementation and we don,t
have to implement it ourselves. You are right about the split though!

Really nice work!

On Saturday, November 12, 2011, Christian Schneider <chris@die-schneider.net>
wrote:
> Hi Raul,
>
> a lock implementation in Hazelcast is surely possible but probably quite
difficult to do right.
> Typically you would work with a kind of heartbeat to tell if the other
nodes are alive.
> The problem arises when the network connect breaks but the nodes are
still alive. Then each would think it is alone and activate.
>
> The database lock is much safer as we can leave that behaviour to the DB
implementation.
>
> Another kind of lock that should work well is a file lock on a shared
file system as Claus proposed. Many Clusters use this for locking.
>
> @Claus: I would rather not move the locking to camel-jdbc as only this
implementation is jdbc specific. How about a camel-failover component? We
could also add file lock impl there.
> Of course camel-core would also be possible but I think it makes sense to
keep such modules out of core.
>
> Christian
>
>
> Am 11.11.2011 16:48, schrieb Raul Kripalani:
>>
>> Hi Christian,
>>
>> Nice work!
>>
>> I'm wondering if we could achieve something similar using the new kind on
>> the block, Hazelcast? It seems to be gaining much traction as of late,
and
>> it could be a possible use case for the camel-hazelcast component?
>>
>> -- Raúl.
>>
>> On 11 November 2011 14:54, Christian Schneider<chris@die-schneider.net
>wrote:
>>
>>> Hi all,
>>>
>>> in most cases when you use camel in production you have to provide some
>>> fault tolerence or high availability.
>>> So that could be easy by just deploying the camel route to two servers.
>>>
>>> In some cases though you have to make sure that only one of the routes
is
>>> running at any time. For example if you use a jpa consumer and want to
make
>>> sure that your messages keep in sequence then you can not simply start
it
>>> twice.
>>>
>>> As I already had this problem some times I finally decided to write a
>>> small project "simplecluster" that solves this problem.
>>>
>>> See my article on:
>>> http://www.liquid-reality.de/**x/XYBe<
http://www.liquid-reality.de/x/XYBe>
>>>
>>> The code can be found on github:
>>> https://github.com/cschneider/**simplecluster<
https://github.com/cschneider/simplecluster>
>>>
>>> Christian
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

-- 
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache Camel <http://camel.apache.org/> Committer
Apache ServiceMix <http://servicemix.apache.org/>  Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
Apache DirectMemory <http://incubator.apache.org/directmemory/> Committer
*

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