Option for time based log rotation about log4j-s3-search HOT 3 CLOSED

Thanks!

Time-based flushing is possible. However, things to watch out for would be:

• Uneven distribution of log events between batches, depending on program behavior.
  • In some cases, there may not even be anything to flush if the period was short enough and/or the program is quiet enough.
  • The flip side of that is if the period were set too long, we risk getting OutOfMemoryError if the program produces log events too much too fast.
• At least one more background thread is needed to periodically flush.

I can try to implement one given the caveats above. I guess the user will need to monitor the host app's logging behavior to find a good setting to use, keeping in mind that there may be some unpleasant surprises if it's configured incorrectly. Size-based flushing doesn't have this problem.

Lastly, I will probably refactor an interface from the current LoggingEventCache to have a hierarchy of EventCache implementations. One will be based on size (the current behavior), and one will be based on time. This will keep the classes simple and specific. (I hesitate to call them SOLID, though.)

from log4j-s3-search.

That would be nice if you'll implement it.
I tried messing with LoggingEventCache for about two hours yesterday.
I tried to set the log files to flush if the eventQueueLength >= capacity OR a specified time interval from the latest flush had elapsed.
(not exactly the same approach as you described above)

Unfortunately, whatever I tried when testing with s3loggersample, the last log would fail to flush and the program seemed to hang and never terminate.
Possibly a deadlock or something.

from log4j-s3-search.

#15 has the first rev of the support for time-based flushing. I'll perform some functional testing before merging.

from log4j-s3-search.