Implement unreliable logging

[Downchuck]

There may be some cases where the log should not be written to disk and/or does not need to be at all reliable.

Add a "no persistence" switch, using the the max batch size as a threshold, throwing an error once the threshold is reached (or possibly deleting records, per config).

[Downchuck]

TL;DR: Need a "max byte (ram) buffer" setting and a setting that says only flush to disk when manually flushed. The prior request is not as good an option. Think: "Journal.WriteType.MANUAL" and if the batch size has been filled, an error is thrown.

Seems that what's more useful is a means to simply turn off any automatic flush/sync and set a limit to the amount of byte buffer (RAM) being used. This way we can say, keep buffering to ram, we can set a timer if we want to sync it to disk, and we can also wait for a failure, at which point we could try to sync to disk or start manually purging. So, it seems with that desired case, it's more a matter of a manual flush and a never-flush switch, along with a max byte size used for the buffer.

[sbtourist]

Think: "Journal.WriteType.MANUAL" and if the batch size has been filled, an error is thrown.

So you want to only flush by calling Journal#sync ?

[Downchuck]

Seems like I've made this feature request more convoluted. What I'm being asked for is to postpone writing to disk until necessary (either X minutes of transpired since a method succeeded or the size of the buffer has grown over X megabytes). How that gets implemented is trickier. Currently I'm just writing to a Byte Array (stream), and handling the switch over to journal.io manually. I was hoping that journal.io could handle the case by tweaking it.

As you talk about flush, my concern is that delete() would no longer work correctly.

My thinking was that if we only flush with manual sync, I can easily handle all the logic I need to, and when one of the flush cases comes up (such as the buffer being too large), I can then run sync() and have an elegant low-code solution. I don't know if that line of thinking works with the current code base (may be non-trivial).

We had looked (on the mailing list) at simply having two journal instances -- one with no persistence, one with persistence, and simply copying data from the non-persist to the safe journal when an event arrives. That seemed like a decent solution - I just thought maybe there was an even better one, with this manual flush idea.