DisableAutoCompaction Bug - Entry compacted error

[vidhikgupta]

Dragonboat gives an option to DisableAutoCompaction.

In my setup running I am running with 1 nodehost which manages 2 shards. Data is committed to one shard and I am using Nodehost GetLogReader function to read the logs and propose to second shard.
I have disabled auto snapshotting and compaction by setting Snapshot entries value as 0and DisableAutoCompaction as true.
I am creating manual snapshots by using RequestSnapshot of nodehost

Additionally I am keeping track of how many entries I have read from log in one variable. The problem here is even if I have disabled auto compaction by setting the field compaction is triggered when the nodes gets restarted , and If I still haven't read some entries from log, program throws "Entry Compacted" error.

Dragonboat version -- 4.0

Expected behavior

Since AutoCompaction is disabled, compaction should not occur

Actual behavior

Entries are getting compacted from log during node restart

Steps to reproduce the behavior

1. Run a 3 node cluster
2. Set config described above
3. Set DisableAutoCompaction to true
4. Send some entries
5. Create manual snapshot using RequestSnapshot - eg after 5 minutes and 100 entries are there in snapshot with compactionIndex as 10 , OverrideCompactionOverhead as true
6. Try to read entries from logreader entries before 10

[lni]

The problem here is even if I have disabled auto compaction by setting the field compaction is triggered when the nodes gets restarted

This is expected. dragonboat manages its own log, it determines when it is okay and safe to delete them. As clearly explained by the docs, DisableAutoCompaction is used to request dragonboat not to perform automatic compaction immediate after taking a snapshot. This is to allow users to pick more suitable times to run compactions for performance reasons only. It doesn't imply anything on whether dragonboat is still allowed run compactions - the library owns & manages its own log, it is always allowed to make compactions.

Another big problem is the GetLogReader method - I have the feeling that allowing direct access to the log might be a little bit immature, there are just corner cases when GetLogReader is used. DisableAutoCompaction and GetLogReader probably give you the false feeling that there is a way to get full control on the logs. Sorry, but that is never the plan.

I'd like to know why you need to use GetLogReader in the first place. Thanks.

[vidhikgupta]

Ok, Thanks for clarification.

So my understanding was that leader log reader also holds the committed entries and is guaranteed to be present in state machine ( I am using IOnDiskStateMachine) . So we can get these entries from leader's logreader also. Is this correct?

[lni]

So we can get these entries from leader's logreader also. Is this correct?

As a part of the ongoing efforts to get v4 released, I am planning to remove the log reader. Directly exposing the internal log to the application is very bad idea. I shouldn't have accept that PR for adding that in the first place.

For your application, if you need to somehow get repeated or random access to the log, you can always sequentially record all those log entries whenever your Update method is called. You can then have full control of the copy you maintain.

[simon28082]

This is expected. dragonboat manages its own log, it determines when it is okay and safe to delete them. As clearly explained by the docs, DisableAutoCompaction is used to request dragonboat not to perform automatic compaction immediate after taking a snapshot. This is to allow users to pick more suitable times to run compactions for performance reasons only. It doesn't imply anything on whether dragonboat is still allowed run compactions - the library owns & manages its own log, it is always allowed to make compactions.

So it's safe to assume that the option, CompactionOverhead, doesn't prevent dragonboat from compressing, it simply doesn't compress immediately upon saving the snapshot right?