Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of seijoed@gmail.com designates
 209.85.213.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=AnEZx+q+i8vxzBwoarl8YqeJ7PR7YC5UWcfVi9jER2QO6CfgU68OzBghYIa8Gr2CJ9
         vMLJe95ecS9NaVC4ljEt6tawOBolSp/RuQCyLQjwrJsahveg17YT8lUQJpo+z/6qhoY5
         3NCUxJ8TBtA56M/ZrRXYwtLcc7NA9e0hT1akA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: sync between two independent brokers
From: Johan Edstrom <seijoed@gmail.com>
In-Reply-To: <BANLkTikuYL9wOv0ek93MsoakUXnYciHLag@mail.gmail.com>
Date: Tue, 10 May 2011 09:57:02 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <24A44A06-81FB-44A9-A00E-301CB0BC7F42@gmail.com>
References: <BANLkTikuYL9wOv0ek93MsoakUXnYciHLag@mail.gmail.com>
To: users@activemq.apache.org

If you use camel, have a DataBase, you can always apply an =
idempotentrepository.

On May 10, 2011, at 5:52 AM, Christoph Burmeister wrote:

> Hi,
>=20
> I have two brokers with nearly the same configuration. They don't
> share a database nor have access to the same filesystem. They will get
> identical messages (Message-reception is not reliable due to
> network-issues), which are received and processed by camel routes
> inside each broker. The result is spit out to the same database (just
> for the processed-messages).
>=20
> Now here's my question: Is there any way to suppress duplicate
> messages in the database? Is there a kind of communication between the
> brokers, or does anyone have a pattern/best practice for this
> "distributed-independent-broker-architecture"? I know, that there is a
> master-slave-concept, but this isn't suitable as it is, because after
> master's death, it requires manual input to sync both instances. A
> more indipendent approach would be much nicer.
>=20
> all ideas are welcome, thanks in advance,
> christoph