On 09/12/2007, Christian Schneider <[EMAIL PROTECTED]> wrote: > > Hello, > > I am searching for a pattern that occurs quite often in EAI but I have not > found it in the list of documented patterns. > > I want to process input from an external source and feed it into a queue. To > make the scenario fault tolerant at least two adapters have to be installed > on two separate machines. They read input from a custom source (in my case I > have to connect to a legacy system via an API and subscribe to a feed). The > catch is the at any time only one of the adapters may be active.
I guess one possible pattern here is Master Slave which is a common solution to this problem; choosing one of the available adapters as being the master; then failing over to a slave if that fails. Its not on Gregor's EIP catalog - but its a common pattern name I'd say. (e.g. ActiveMQ implements it). > One way to achieve this is sending heartbeats on a topic and having a rule > which adapter should be active. At the moment I start all adapters inactive > and give them a weight setting. Now if an adapter receives no heartbeats or > only heartbeats from adapters with lower weights it will activate. > > While I probably can implement this on my own I am wondering if someone has > already solved the problem. Yeah - your solution sounds about right to me. Choosing the master often uses the Paxos algorithm to ensure consensus.. http://en.wikipedia.org/wiki/Paxos_algorithm Though you can approximate this using weightings (maybe using IP address if weightings are equal) though the downside is things like network splits (e.g. your network is split into 2 parts and each elects a master) etc. The ActiveCluster codebase implements a simple form of Paxos; but the code is a little crusty (its fallen into disuse). I guess we could bring it back to life again; maybe as part of Camel so that it can be multi-protocol. I've often thought a really simple Master/Slave implementation could be to use a database as its got pessimistic locking & is a really simple way to reach consensus across a number of processes and you only need to use the database on startup or when the master fails - so its not really a single point of failure. Also most systems these days need a database of some kind to function; so using a table or two to figure out who is the master seems a reasonable approach; which also deals nicely with the network split issue. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
