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 16,
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, Ralph Goers
> wrote:
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
> compress them. Due to fi
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 processes at least.
>
>
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 don't think Java s
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 aachen.de> wrote:
> >
> > with-in log4j?
> >
>
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
>> compression as a viable approach.
>>
>> Ralph
>>
>>> On Nov 1
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
> > wrote:
> >
> > thanks for info matt, was planning to use
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
> wrote:
>
> thanks for info matt, was planning to use this on some other project in mind
> ( might pick your brain on that later ;) )
>
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
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 native
> 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 wou
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 handle situation:
>
> we are on HP/LL
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
sta
14 matches
Mail list logo