Re: Log4j 2.10

Well, I thought I would have time today but it is rapidly getting away from me. I will have time on Saturday for sure. Ralph > On Nov 16, 2017, at 1:38 PM, Mikael Ståldal wrote: > > OK for me. Thanks for the RM work. > > > On 2017-11-16 05:31, Ralph Goers wrote: >> Unless

Re: Log4j 2.10

OK for me. Thanks for the RM work. On 2017-11-16 05:31, Ralph Goers 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.

Re: Log4j 2.10

OK for me. Thanks for the RM work. On 2017-11-16 05:31, Ralph Goers 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.

Re: Compression on rolling leads to OOM

What do you mean “It is the same as running it out of the jvm”? ProcessBuilder creates processes that execute commands. They don’t have to be Java. That said, it certainly could be a Java environment that we control that can only run the asynchronous actions Log4j supports. Ralph > On Nov

Re: Compression on rolling leads to OOM

I should have used “spawn” instead of “fork”. Ralph > On Nov 16, 2017, at 11:34 AM, Matt Sicker wrote: > > I don't think Java supports process forking (not even sure if Windows > does), but you can execute and control processes at least. > > On 16 November 2017 at 12:28,

Re: Compression on rolling leads to OOM

well that’s the idea. have log4j rotate files, keep it in a separate directory and a script or an agent take care of compression and shipping. On 17 Nov 2017, 12:07 AM +0530, Matt Sicker , wrote: > As for an agent, that'd be a separate daemon to watch your log files and >

Re: Compression on rolling leads to OOM

well, ProcessBuilder.start() and Runtime.exec is one way to go but it’s the same as running it out of jvm. On 17 Nov 2017, 12:05 AM +0530, Matt Sicker , wrote: > I don't think Java supports process forking (not even sure if Windows > does), but you can execute and control

Re: Compression on rolling leads to OOM

As for an agent, that'd be a separate daemon to watch your log files and compress them. Due to file handle issues with Java, I don't think said agent could handle file rotations and such without some convoluted staging area. On 16 November 2017 at 12:34, Matt Sicker wrote: > I

Re: Compression on rolling leads to OOM

I don't think Java supports process forking (not even sure if Windows does), but you can execute and control processes at least. On 16 November 2017 at 12:28, Ralph Goers wrote: > Sure, why not? > > Ralph > > > On Nov 16, 2017, at 11:24 AM, Chandra

Re: Compression on rolling leads to OOM

Sure, why not? Ralph > On Nov 16, 2017, at 11:24 AM, Chandra > wrote: > > with-in log4j? > > On 16 Nov 2017, 11:46 PM +0530, Ralph Goers , > wrote: >> I could see forking a process instead of spawning a thread to perform the

Re: Compression on rolling leads to OOM

with-in log4j? On 16 Nov 2017, 11:46 PM +0530, Ralph Goers , wrote: > I could see forking a process instead of spawning a thread to perform the > compression as a viable approach. > > Ralph > > > On Nov 16, 2017, at 10:01 AM, Chandra

Re: Compression on rolling leads to OOM

thanks for info matt, was planning to use this on some other project in mind ( might pick your brain on that later ;) ) separating it out the compression to external process isn’t necessarily a bad idea, but having non-reliable scripts is. As it so happened many times before. I’d rather depend

Re: Compression on rolling leads to OOM

I brought up Snappy only because I used their off-heap API recently. Snappy is more about real time compression rather than size (I think snappy files tend to be larger than gzip files, but take less resources to compress and decompress). The idea here is to offer support via libraries using

Re: Compression on rolling leads to OOM

> What if compression worked off-heap off-heap compression sounds interesting. Let me check if I can find any. Snappy’s compression is a different altogether,  I am not necessarily looking for a different compression formats, as I’d have add support for it in downstream.  Standard bz2 , gzip

Re: Log4j 2.10

Go for it! I may follow up with a Log4j Scala 11.1 release after to get dependencies up to date. On 16 November 2017 at 00:50, Remko Popma wrote: > No objection, and thanks for RM-ing! > > Remko > > > > > On Nov 16, 2017, at 14:04, Gary Gregory

Re: Compression on rolling leads to OOM

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 wrote: > Guys, > > I need some input on how this

Re: [jira] [Updated] (LOG4J2-2121) DefaultRolloverStrategy max = 5 does not limit nuber of files

From your configuration the limit is 5 per rollover interval. You are specifying an interval of one day. Are you getting more than 5 per day? Ralph > On Nov 16, 2017, at 1:44 AM, Seweryn Habdank-Wojewodzki (JIRA) > wrote: > > > [ >