activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.org>
Subject Re: Replication and client transactions
Date Tue, 21 Feb 2017 15:46:05 GMT
There may be some confusion here on how Artemis works in general with I/O.  I/O operations
(including replication) *are* done asynchronously as you found.  However, this isn't incompatible
with the guarantees you mentioned in your earlier message.  If a guarantee is necessary, the
code will simply wait for a callback to ensure the I/O was successful.  This strategy can
boost performance considerably.  Consider the replication scenario where I/O needs to be done
across the network as well as a local disk.  The simplest and worst performing approach would
be to write the data to local disk and block while waiting for the disk sync and once the
disk was synced then write the data to the network socket and block while waiting for a reply.
 The approach that Artemis takes is to do both operations asynchronously and then wait (if
necessary) for completion callbacks.  This approach allows both operations to be done at the
same time which can greatly reduce the wait time overall.

Hope that helps.


Justin

----- Original Message -----
From: "Alec Henninger" <alechenninger@gmail.com>
To: users@activemq.apache.org
Sent: Sunday, February 19, 2017 9:28:12 PM
Subject: Re: Replication and client transactions

Thank you very much for your time.

On Sat, Feb 18, 2017 at 10:16 PM Justin Bertram <jbertram@apache.org> wrote:

> > Given I have a broker with for example two backups, configured with
> journal
> > replication (not shared storage), is there a way to guarantee a message
> has
> > successfully replicated before completing a write?
>
> Assuming the message you send is durable then this happens automatically.
> The producer will not receive a reply back from the broker until the
> message has been replicated successfully.
>

This may be asking a lot, but is it possible to direct me a little bit to
where this is expressed in the code? I've been looking around the client
and server code trying to understand how this is enforced and as far as I
can tell it looks like replication is done asynchronously. I obviously
don't doubt your answer, I'm just trying to understand how it works.


>
> > Is it possible to configure how many backups a message should be
> replicated
> > to before it is successful (such as a majority of them)?
>
> Although multiple backups can be configured it's important to know that
> only 1 backup actually receives the replicated data.  In this use-case when
> the live broker fails and the backup with the replicated data takes over
> then one of the "extra" backups becomes a backup to the new live broker.
>
> > Is a message consumable before it has been replicated to multiple
> backups?
>
> No, I don't believe so.
>
>
> Justin
>
> ----- Original Message -----
> From: "Alec Henninger" <alechenninger@gmail.com>
> To: users@activemq.apache.org
> Sent: Saturday, February 18, 2017 3:42:11 PM
> Subject: Re: Replication and client transactions
>
> Woops, thought the list was Artemis specific. Yes I'm using Artemis in this
> example.
>
> On Sat, Feb 18, 2017, 1:38 PM Justin Bertram <jbertram@apache.org> wrote:
>
> > Are you using ActiveMQ Artemis?
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Alec Henninger" <alechenninger@gmail.com>
> > To: users@activemq.apache.org
> > Sent: Saturday, February 18, 2017 11:50:18 AM
> > Subject: Replication and client transactions
> >
> > Hi all,
> >
> > Given I have a broker with for example two backups, configured with
> journal
> > replication (not shared storage), is there a way to guarantee a message
> has
> > successfully replicated before completing a write?
> >
> > Does this happen automatically, or is configuration necessary to achieve
> > this?
> >
> > Is it possible to configure how many backups a message should be
> replicated
> > to before it is successful (such as a majority of them)?
> >
> > Is a message consumable before it has been replicated to multiple
> backups?
> >
> > Thank you very much for your time,
> > Alec
> >
>

Mime
View raw message