You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by robert geiger <ro...@ampool.io> on 2016/06/09 21:37:06 UTC

OplogCompactor question

Was looking into OplogCompactor due to excessive info level log messages and noticed that (1) compaction continuously runs using the disk store task thread pool (is re-scheduled with no delay); and (2) info level messages are in the nominal (no errors) code path.

It would seem that info level messages should not be in a continuously running maintenance thread, or am I missing something here?

Thanks,
Bob

_______________________
Robert Geiger
Chief Architect, Ampool Inc.
+1 408-833-4527


Re: OplogCompactor question

Posted by Darrel Schneider <ds...@pivotal.io>.
It will only run if it can find at least one oplog that is ready for
compaction. Once "getOplogsToBeCompacted()" returns null then a new
compaction task will not be scheduled until a new oplog becomes compactable
(see com.gemstone.gemfire.internal.cache.PersistentOplogSet.addToBeCompacted(Oplog)).

The info level messages you see from the compactor should keep telling you
different oplog ids.

On Thu, Jun 9, 2016 at 2:37 PM, robert geiger <ro...@ampool.io> wrote:

> Was looking into OplogCompactor due to excessive info level log messages
> and noticed that (1) compaction continuously runs using the disk store task
> thread pool (is re-scheduled with no delay); and (2) info level messages
> are in the nominal (no errors) code path.
>
> It would seem that info level messages should not be in a continuously
> running maintenance thread, or am I missing something here?
>
> Thanks,
> Bob
>
> _______________________
> Robert Geiger
> Chief Architect, Ampool Inc.
> +1 408-833-4527
>
>