Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
Sender: tbain98@gmail.com
In-Reply-To: <1508528689643-0.post@n4.nabble.com>
References: <1508528689643-0.post@n4.nabble.com>
From: Tim Bain <tbain@alumni.duke.edu>
Date: Fri, 20 Oct 2017 21:38:34 -0600
Message-ID: <CAPVVMa_vsYe8DHCFNJv+9YQQRVX-hTTmML=BhyQ0oz3VejNnsg@mail.gmail.com>
Subject: Re: Checkpoint worker; what's it doing?
To: ActiveMQ Users <users@activemq.apache.org>
Content-Type: multipart/alternative; boundary="001a1145a84e247996055c0654ff"
archived-at: Sat, 21 Oct 2017 03:39:08 -0000

--001a1145a84e247996055c0654ff
Content-Type: text/plain; charset="UTF-8"

The org.apache.activemq.store.kahadb.MessageDatabase
<https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java>.CheckpointRunner
does the following:

   1. If the journal does periodic disk syncing rather than immediate
   syncing and the sync period has elapsed, it causes unsynced content to be
   written to disk.
   2. If the cleanup interval has elapsed, it performs cleanup (identifies
   and deletes files that contain no unacknowledged messages, performs ack
   compaction if enabled, flushes any pending index-modifying operations in
   the pagefile, and then deletes any files that are no longer referenced).
   3. If the checkpoint interval has elapsed, it performs a checkpoint
   (flushes any pending index-modifying operations in the pagefile, and then
   deletes any files that are no longer referenced) - basically a cleanup
   without the search for files that can be GC'ed and the ack compaction.

The consequences of increasing the period of these events are the following:

   1. If you're doing periodic disk syncing, you incur a greater risk of
   losing data. If not, there is no effect on this particular dimension.
   2. Because the pagefile stays the same but you're going longer before
   flushing, you're more likely to fill it before the next flush, in which
   case writes are done either in the background or synchronously within the
   current thread, which may be less efficient. So your throughput could drop,
   but how much would probably depend heavily on how heavily you're using the
   persistent store.

You asked whether there was any negative impact of having it run less
frequently, but I'll turn the question around: what positive impact do you
believe you'll achieve by having it run less frequently, such that it's
worth 1) your time, and 2) the increased odds of hitting edge cases caused
by running in an uncommonly-used configuration? Have you measured a
performance impact of the operations of that thread?

Tim

P.S. All information in this email comes from some time this evening
reading through this code for the first time, so it's entirely possible
that I've missed or misrepresented something here. YMMV.


On Fri, Oct 20, 2017 at 1:44 PM, Raffi <raffi.onjava@gmail.com> wrote:

> It's my understanding each kahadb is assigned a checkpoint thread which,
> every 5s (default), wakes up and does something; what is it doing, and is
> there any negative impact if the interval is increased to 60s or 120s? We
> are using persistent messages, jsyk
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

--001a1145a84e247996055c0654ff--