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" <alechennin...@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 <jbert...@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" <alechennin...@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 <jbert...@apache.org> wrote:
>
> > Are you using ActiveMQ Artemis?
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Alec Henninger" <alechennin...@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
> >
>

Reply via email to