What if compression worked off-heap like with some of the native implementations of codecs? I'm thinking of this one < https://github.com/xerial/snappy-java> for example.
On 15 November 2017 at 23:41, Chandra <[email protected]> wrote: > Guys, > > I need some input on how this handle situation: > > we are on HP/LL setting where the incoming requests are processed and > logged ( buffered, of course with “async logging”). There are some > situations where due to spikes in the volume of requests, the compression > on rolling creates memory starvation. > > Now, a straight forward fix would to remove it from the “context” of jvm > and use a script to monitor and compress it timely. as low-hanging the > solution may be, I am skeptical of this solution as the script _may_ fail > leading to disk starvation(!) > > I am looking for an alternate and _full-proof_ solution for this > situation. Any thoughts, suggestions would be useful and appreciated. > > thanks! > Chandra > > On 16 Nov 2017, 10:01 AM +0530, Ralph Goers <[email protected]>, > wrote: > > Unless someone objects I plan to start the release process for Log4j > 2.10 tomorrow. I had wanted to include a fix for LOG4J2-2106 but the > problem only occurs in rare situations and I am not sure how to fix it yet. > There are a lot of other issues that deserve looking at but nothing I can > see that warrants waiting on. > > > > Ralph > -- Matt Sicker <[email protected]>
