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 christiangrassi@gmail.com
 designates 74.125.82.182 as permitted sender)
MIME-Version: 1.0
References: 
 <CAAZU44m+j7ef3ouD+H7GP_nNjRomvc+=XqJyZHup5qcatQ0Gzw@mail.gmail.com>
 <CAH+vQmMoGj+uaZaeXQ7Ze89UzHcYgw=2SQQNxmhjmS7a9BqhLA@mail.gmail.com>
 <1426278627291-4693192.post@n4.nabble.com>
 <CAAZU44=VuUTjN0BJPZrfBU5kLNdt0Rj2EYK4y32ENMf_QTHJ5Q@mail.gmail.com>
 <1426283208357-4693203.post@n4.nabble.com>
 <CAAZU44n+OWrvLw9mYJv5-E+1jhDcycNLybyR40pgnOBqhdinAw@mail.gmail.com>
 <CAHrqXNHsg-RJrYGGZam8apa_oOSN6frGUkOnrsLNVdc_KN-kBQ@mail.gmail.com>
 <CAAZU44kV=w+sNf5_n7d2QNQqrjfX6FALpCSnaZx8hvM1M+1u7g@mail.gmail.com>
 <CAPVVMa98qZzqPE099FNOVHSMCKD2k2GJB58uJwCm=Vx4YL=KZQ@mail.gmail.com>
From: Christian Grassi <christiangrassi@gmail.com>
Date: Sat, 14 Mar 2015 15:56:42 +0000
Message-ID: 
 <CAHrqXNH=+QSw_oRapOMqhn7aR0TnSGO9qg7gNNaUHb_QfMcikQ@mail.gmail.com>
Subject: Re: Lots of small ActiveMQ instances or one big one?
To: ActiveMQ Users <users@activemq.apache.org>
Content-Type: multipart/alternative; boundary=047d7b5d22b0d2fd53051141a9d8

--047d7b5d22b0d2fd53051141a9d8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes Tim, this was my point, if the producer receives the ack, it should be
when the message is persistet on disk.

Chris

Il giorno sab 14 mar 2015 15:32 Tim Bain <tbain@alumni.duke.edu> ha scritto=
:

> I think the difference is that an ack packet (telling the sender that it
> can discard the message because the broker now has it stored and the
> sender's copy is no longer needed as a backup) is sent after a successful
> write to disk, so the consequences of a failed disk write are different
> than a failed Ethernet or queue write.
>
> So if you batch disk writes, you either batch acks (which has a negative
> performance impact; I'm not sure if the loss will be greater or less than
> the gain from batching writes, but at a minimum it'll decrease the expect=
ed
> improvement from batching writes) or you optimistically ack before the bi=
ts
> hit the disk (which violates the JMS contract because it allows message
> loss if the server crashes before the batch is written).
> On Mar 13, 2015 7:57 PM, "Kevin Burton" <burton@spinn3r.com> wrote:
>
> > > Regarding batching in my opinion it is right, even if is not the most
> > performing solution, to have a fsync per msg as otherwise in case of
> outage
> > you lose more messages
> >
> > To clarify, you get the same mathematical / functional properties of
> > messages, just in the case of smart batching, you get MUCH better
> > throughput.
> >
> > While the packet is over the ethernet it=E2=80=99s not sync=E2=80=99d .=
. while it=E2=80=99s
> waiting
> > in queue, it=E2=80=99s not sync=E2=80=99d.
> >
> > The change is that instead of taking one message at a time, and writing=
,
> > then syncing each one, you either read N messages at once, or the entir=
e
> > queue.
> >
> > The performance improvement can be dramatic. (100x).
> >
> >
> > On Fri, Mar 13, 2015 at 5:59 PM, Christian Grassi <
> > christiangrassi@gmail.com
> > > wrote:
> >
> > > Hi Kevin,
> > > just curios how many messages per second you are seeing?
> > > Regarding batching in my opinion it is right, even if is not the most
> > > performing solution, to have a fsync per msg as otherwise in case of
> > outage
> > > you lose more messages. Personally speaking in a persistent queue if
> the
> > > producer is acknowledged that a message is in the queue it should be
> sent
> > > and persisted.
> > > Just my opinion
> > >
> > > Chris
> > >
> > > Il giorno ven 13 mar 2015 23:06 Kevin Burton <burton@spinn3r.com> ha
> > > scritto:
> > >
> > > > Does ActiveMQ do an fsync per message?
> > > >
> > > > Why not do smart batching:
> > > >
> > > > http://mechanical-sympathy.blogspot.com/2011/10/smart-batching.html
> > > >
> > > > This way the messages could be elided, and one fsync called on all =
of
> > > them.
> > > >
> > > > Maybe it already does, but the comment that each messages requires =
a
> > sync
> > > > seems to hint that this could be more efficient.
> > > >
> > > > On Fri, Mar 13, 2015 at 2:46 PM, artnaseef <art@artnaseef.com>
> wrote:
> > > >
> > > > > I think they are in-line.  More producers generally mean more
> > > concurrent
> > > > > work
> > > > > for the broker, as a single producer sends all of its messages
> > serially
> > > > to
> > > > > the broker.  Similar logic applies to consumers.
> > > > >
> > > > > More destinations generally forces more producers and consumers,
> > > although
> > > > > it
> > > > > doesn't have to.
> > > > >
> > > > > Is there something more specific that doesn't seem to match?
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > > http://activemq.2283324.n4.nabble.com/Lots-of-small-
> > > > ActiveMQ-instances-or-one-big-one-tp4693133p4693203.html
> > > > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Founder/CEO Spinn3r.com
> > > > Location: *San Francisco, CA*
> > > > blog: http://burtonator.wordpress.com
> > > > =E2=80=A6 or check out my Google+ profile
> > > > <https://plus.google.com/102718274791889610666/posts>
> > > > <http://spinn3r.com>
> > > >
> > >
> >
> >
> >
> > --
> >
> > Founder/CEO Spinn3r.com
> > Location: *San Francisco, CA*
> > blog: http://burtonator.wordpress.com
> > =E2=80=A6 or check out my Google+ profile
> > <https://plus.google.com/102718274791889610666/posts>
> > <http://spinn3r.com>
> >
>

--047d7b5d22b0d2fd53051141a9d8--