On Tuesday 03 Apr 2012 02:26:03 Zlatin Balevsky wrote:
> On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
> wrote:
> > On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
> >> >>
> >> >> In 'log.info("Random message: %s", obj.toString())' evaluating
> >> >> 'obj.toString()' was what caused
On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
> >>
> >> In 'log.info("Random message: %s", obj.toString())' evaluating
> >> 'obj.toString()' was what caused issues, not recycling it, or so I believe
> >> to remember.
> >
> > You don't need to call obj.toString() before calling log() -
On Tuesday 03 Apr 2012 02:26:03 Zlatin Balevsky wrote:
On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
In 'log.info(Random message: %s, obj.toString())' evaluating
'obj.toString()' was what
On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
wrote:
> On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
>> >>
>> >> In 'log.info("Random message: %s", obj.toString())' evaluating
>> >> 'obj.toString()' was what caused issues, not recycling it, or so I
>> >> believe to remember.
>> >
On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
In 'log.info(Random message: %s, obj.toString())' evaluating
'obj.toString()' was what caused issues, not recycling it, or so I believe
to remember.
You don't need to call obj.toString() before calling log() - just pass the
On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
In 'log.info(Random message: %s, obj.toString())' evaluating
'obj.toString()' was what caused issues, not recycling it, or so I
believe to remember.
>>
>> In 'log.info("Random message: %s", obj.toString())' evaluating
>> 'obj.toString()' was what caused issues, not recycling it, or so I believe
>> to remember.
>
> You don't need to call obj.toString() before calling log() - just pass the
> object itself. Then the only overheads are:
> 1)
On Wednesday 28 Mar 2012 19:56:19 postwall-freenet at yahoo.de wrote:
> If I remember right then the main issue with debug logging wasn't GC but that
> generating some of the log string arguments in freenet was simply very
> resource intensive in itself.
I'm not sure. I do remember it greatly
On Wednesday 28 Mar 2012 19:56:19 postwall-free...@yahoo.de wrote:
If I remember right then the main issue with debug logging wasn't GC but that
generating some of the log string arguments in freenet was simply very
resource intensive in itself.
I'm not sure. I do remember it greatly
In 'log.info(Random message: %s, obj.toString())' evaluating
'obj.toString()' was what caused issues, not recycling it, or so I believe
to remember.
You don't need to call obj.toString() before calling log() - just pass the
object itself. Then the only overheads are:
1) Calling the
a non Java-dev here, so ignore if applicable. :P
Von: Ximin Luo
An: devl at freenetproject.org
Gesendet: 4:33 Samstag, 24.M?rz 2012
Betreff: Re: [freenet-dev] Logging in Fred
I see.
Actually we didn't even need the side effects thing - I did notice that yo
here, so ignore if applicable. :P
Von: Ximin Luo infini...@gmx.com
An: devl@freenetproject.org
Gesendet: 4:33 Samstag, 24.März 2012
Betreff: Re: [freenet-dev] Logging in Fred
I see.
Actually we didn't even need the side effects thing - I did notice that your
On 24-03-2012 09:26, Marco Schulze wrote:
> I finally got freenet.jar compiled and profiled. First, size-related
> numbers:
>
> Number of lines removed: ~5000
> freenet.jar shrink: ~200k
>
> And profiling data (see below for details):
>
> freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
On 24-03-2012 09:26, Marco Schulze wrote:
I finally got freenet.jar compiled and profiled. First, size-related
numbers:
Number of lines removed: ~5000
freenet.jar shrink: ~200k
And profiling data (see below for details):
freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
Oops. Most
I finally got freenet.jar compiled and profiled. First, size-related
numbers:
Number of lines removed: ~5000
freenet.jar shrink: ~200k
And profiling data (see below for details):
freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
freenet.support.Log.isLoggable: 0.09% (17)
I see.
Actually we didn't even need the side effects thing - I did notice that your
example stopped doing GC when setting "shouldLog = false" always, so I tried to
introduce your "if (shouldLog) { shouldLog = false; }" into my example, but was
still unable to reproduce GC. Then changing
-
On 24/03/12 02:44, Zlatin Balevsky wrote:
> Wrong. Extracting the log statement into its own method and calling
> that method inside the while loop still creates garbage. Stack frames
> are different.
>
How do you explain the results obtained from running my test code, then? Turn
on
On 24/03/12 01:56, Zlatin Balevsky wrote:
> Not really. Here, I'll change my call to allocate everything on one level:
>
> while (true) {
> log(" list size is {1} ",
> new Integer(listToLog.size()));
> }
>
> I don't see how using this you can log
Sorry, bad typing. "inside its own" not "inside its only".
On 24/03/12 01:33, Ximin Luo wrote:
> That is because in your example you're allocating all those new Object()s in
> the same stack frame, so the allocator runs out of space on the stack.
>
> If you put the call to log(x, new Object())
That is because in your example you're allocating all those new Object()s in
the same stack frame, so the allocator runs out of space on the stack.
If you put the call to log(x, new Object()) inside its only function call, each
Object will be destroyed once that call exits, and no GC occurs.
It doesn't look like a big deal but if all of Fred was using lazy
evaluation for logging it would make one common use case very
annoying:
Say I'm working on a specific class and need to run that class with
debug logging enabled. This would have the side effect of changing
the compiled LOG.debug(
As to why it still creates garbage even if you do not touch the
arguments in the testWithout method, I would guess that different
inlining rules apply to large methods, small methods and methods that
are already inlined within other methods.
To give definitive answer I'll have to look through the
Your test has nothing to do with stack allocation because you never
use the objects that you pass to the log_info method so JIT removes
them. Apply the following patch and see yourself create garbage in
both testWith and testWithout.
--- Test2.java 2012-03-23 23:01:05.540475497 -0400
+++
I finally got freenet.jar compiled and profiled. First, size-related
numbers:
Number of lines removed: ~5000
freenet.jar shrink: ~200k
And profiling data (see below for details):
freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
freenet.support.Log.isLoggable: 0.09% (17)
Wrong. Extracting the log statement into its own method and calling
that method inside the while loop still creates garbage. Stack frames
are different.
Read again exactly how Escape Analysis works. The objects it prevents
from creating do not appear in heap histograms. Take a "jmap -histo
"
The only bug-vector I see in the current predicate approach is that
when used incorrectly it cause the size of methods to explode. There
are some hard-coded thresholds for the method size in bytecodes that
turn off some or all JIT optimizations; there are also a whole host of
compilation
Not really. Here, I'll change my call to allocate everything on one level:
while (true) {
log(" list size is {1} ",
new Integer(listToLog.size()));
}
I don't see how using this you can log primitive values without garbage.
On Fri, Mar 23, 2012 at 9:33
You're right, the example you gave will put the arguments on the
stack. I wanted to clarify Escape Analysis in its current form works
only if a new object doesn't exit the stack frame where it's created.
Because of that, the moment you do something slightly more complicated
you will create
On Friday 23 Mar 2012 16:00:15 Marco Schulze wrote:
> Yes, and yes.
>
> On 23-03-2012 12:43, Matthew Toseland wrote:
> > On Friday 23 Mar 2012 15:29:44 you wrote:
> >> Right now, the map is only used to list class thresholds which are
> >> different from the global threshold, which means it is
On Friday 23 Mar 2012 15:29:44 you wrote:
> Right now, the map is only used to list class thresholds which are
> different from the global threshold, which means it is empty 99% of the
> time. This is the simplest solution, but it also means that the
> possibility of lock contention is way
On Friday 23 Mar 2012 00:18:02 Marco Schulze wrote:
> I already have all but log rotation and async ready, and haven't yet
> found a single benchmark supporting the use of a branch as the
> performance holy grail. For example (outputting to /dev/null):
>
> public static void main (String[]
On Friday 23 Mar 2012 11:35:44 Ximin Luo wrote:
> lol, OK.
>
> I am just annoyed with everyone that keeps arguing "we need to implement our
> own generic X framework because of minor issue Y whose importance I am
> over-inflating, even though countless other projects with similar requirements
>
Sure. Since the class name lookups will only be used for debugging, they
can be as generic as necessary, as long it doesn't add any requirements
to users. Match-on-load and match-on-demand are both fine.
On 23-03-2012 13:19, Matthew Toseland wrote:
> On Friday 23 Mar 2012 16:00:15 Marco Schulze
Yes, and yes.
On 23-03-2012 12:43, Matthew Toseland wrote:
> On Friday 23 Mar 2012 15:29:44 you wrote:
>> Right now, the map is only used to list class thresholds which are
>> different from the global threshold, which means it is empty 99% of the
>> time. This is the simplest solution, but it
Right now, the map is only used to list class thresholds which are
different from the global threshold, which means it is empty 99% of the
time. This is the simplest solution, but it also means that the
possibility of lock contention is way higher. However, unless this
proves to be very bad in
lol, OK.
I am just annoyed with everyone that keeps arguing "we need to implement our
own generic X framework because of minor issue Y whose importance I am
over-inflating, even though countless other projects with similar requirements
get around these adequately".
To anyone doing refactoring
On Fri, Mar 23, 2012 at 8:58 AM, David ?Bombe? Roden <
bombe at pterodactylus.net> wrote:
> Yes, kids, both your penisses are incredibly long. Now shut up and let the
> grown-ups do some refactoring.
>
>
> Greetings,
>
>David
>
>
Thanks daddy !
Nicolas
-- next part
Yes, kids, both your penisses are incredibly long. Now shut up and let the
grown-ups do some refactoring.
Greetings,
David
On 23.03.2012, at 04:47, Ximin Luo wrote:
> LOL, are you kidding me?
>
> Please point to the exact lines of code that results in "double-digit
> millisecond
No one is benchmarking JRE's JIT. If you look closer, there are figures
with the average runtime without JIT, exactly to avoid overspecialization.
With JIT, there is a reduction of 0.02% in runtime. Without JIT, this
becomes 0.06%. Negligible to all but the few people who do everything in
LOL, are you kidding me?
Please point to the exact lines of code that results in "double-digit
millisecond pauses"?
Talk is cheap, show us some numbers.
BTW, the "example" I gave is not real code, and contains no variable
declarations, so your challenge makes no sense. Since you apparently
The "drastically cleaner syntax" is a red herring. Most of the time when you
are doing a complex calculation, you are not going to put it on one line
anyway. In such cases, the function you are using to do the calculation might
as well be the toString() method of some object.
Your claim of
Yes, kids, both your penisses are incredibly long. Now shut up and let the
grown-ups do some refactoring.
Greetings,
David
On 23.03.2012, at 04:47, Ximin Luo wrote:
LOL, are you kidding me?
Please point to the exact lines of code that results in double-digit
millisecond pauses?
On Fri, Mar 23, 2012 at 8:58 AM, David ‘Bombe’ Roden
bo...@pterodactylus.net wrote:
Yes, kids, both your penisses are incredibly long. Now shut up and let the
grown-ups do some refactoring.
Greetings,
David
Thanks daddy !
Nicolas
___
lol, OK.
I am just annoyed with everyone that keeps arguing we need to implement our
own generic X framework because of minor issue Y whose importance I am
over-inflating, even though countless other projects with similar requirements
get around these adequately.
To anyone doing refactoring
On Friday 23 Mar 2012 11:35:44 Ximin Luo wrote:
lol, OK.
I am just annoyed with everyone that keeps arguing we need to implement our
own generic X framework because of minor issue Y whose importance I am
over-inflating, even though countless other projects with similar requirements
get
On Friday 23 Mar 2012 00:18:02 Marco Schulze wrote:
I already have all but log rotation and async ready, and haven't yet
found a single benchmark supporting the use of a branch as the
performance holy grail. For example (outputting to /dev/null):
public static void main (String[] args) {
Right now, the map is only used to list class thresholds which are
different from the global threshold, which means it is empty 99% of the
time. This is the simplest solution, but it also means that the
possibility of lock contention is way higher. However, unless this
proves to be very bad in
On Friday 23 Mar 2012 15:29:44 you wrote:
Right now, the map is only used to list class thresholds which are
different from the global threshold, which means it is empty 99% of the
time. This is the simplest solution, but it also means that the
possibility of lock contention is way higher.
Yes, and yes.
On 23-03-2012 12:43, Matthew Toseland wrote:
On Friday 23 Mar 2012 15:29:44 you wrote:
Right now, the map is only used to list class thresholds which are
different from the global threshold, which means it is empty 99% of the
time. This is the simplest solution, but it also means
Sure. Since the class name lookups will only be used for debugging, they
can be as generic as necessary, as long it doesn't add any requirements
to users. Match-on-load and match-on-demand are both fine.
On 23-03-2012 13:19, Matthew Toseland wrote:
On Friday 23 Mar 2012 16:00:15 Marco Schulze
You're right, the example you gave will put the arguments on the
stack. I wanted to clarify Escape Analysis in its current form works
only if a new object doesn't exit the stack frame where it's created.
Because of that, the moment you do something slightly more complicated
you will create
That is because in your example you're allocating all those new Object()s in
the same stack frame, so the allocator runs out of space on the stack.
If you put the call to log(x, new Object()) inside its only function call, each
Object will be destroyed once that call exits, and no GC occurs.
Sorry, bad typing. inside its own not inside its only.
On 24/03/12 01:33, Ximin Luo wrote:
That is because in your example you're allocating all those new Object()s in
the same stack frame, so the allocator runs out of space on the stack.
If you put the call to log(x, new Object()) inside
Not really. Here, I'll change my call to allocate everything on one level:
while (true) {
log( list size is {1} ,
new Integer(listToLog.size()));
}
I don't see how using this you can log primitive values without garbage.
On Fri, Mar 23, 2012 at 9:33
The only bug-vector I see in the current predicate approach is that
when used incorrectly it cause the size of methods to explode. There
are some hard-coded thresholds for the method size in bytecodes that
turn off some or all JIT optimizations; there are also a whole host of
compilation
On 24/03/12 01:56, Zlatin Balevsky wrote:
Not really. Here, I'll change my call to allocate everything on one level:
while (true) {
log( list size is {1} ,
new Integer(listToLog.size()));
}
I don't see how using this you can log primitive values
Wrong. Extracting the log statement into its own method and calling
that method inside the while loop still creates garbage. Stack frames
are different.
Read again exactly how Escape Analysis works. The objects it prevents
from creating do not appear in heap histograms. Take a jmap -histo
pid
I see.
Actually we didn't even need the side effects thing - I did notice that your
example stopped doing GC when setting shouldLog = false always, so I tried to
introduce your if (shouldLog) { shouldLog = false; } into my example, but was
still unable to reproduce GC. Then changing
-
It doesn't look like a big deal but if all of Fred was using lazy
evaluation for logging it would make one common use case very
annoying:
Say I'm working on a specific class and need to run that class with
debug logging enabled. This would have the side effect of changing
the compiled LOG.debug(
The example you provide is fast because it does not do any object
allocation. Please don't take my word for it - download (or better
yet, build one yourself) a "fastdebug" build from openjdk.org and look
at the opto-assembly that gets generated when you pass the
"-XX:+PrintOptoAssembly" switch.
My claim is based on day-to-day observations of hundreds of JVMs under
various load scenarios.
Your claim that modern JVMs "do escape analysis" is worthless as it shows
that you have merely read some blog posts, and even those you've read only
partially. Please point to the exact lines of code
Lazy evaluation is trivial.
Log.info("{1} did {2}",
new Object(){ public String toString() { return ITEM_1; } },
new Object(){ public String toString() { return ITEM_2; } }
);
Garbage collection with short-lived objects costs next to nothing.
On 22/03/12 21:15, Zlatin Balevsky wrote:
>
I already have all but log rotation and async ready, and haven't yet
found a single benchmark supporting the use of a branch as the
performance holy grail. For example (outputting to /dev/null):
public static void main (String[] args) {
for (int i = 0; i < 100; i++) {
Double-digit millisecond pauses are not nothing. They may be acceptable
right now but unless you can offer a drastically cleaner syntax Fred should
stick with predicates as they are handled much better by the hotspot jit.
On Mar 22, 2012 5:36 PM, "Ximin Luo" wrote:
> Lazy evaluation is trivial.
Constructing the logging strings is half of the problem. The amount of
garbage they will generate will result in significantly more time in
garbage collection pauses.
Unless you figure out a way to mimic lazy evaluation you have to live with
the isLoggable predicates. varargs are not an option
On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
> There are basically two big concerns regarding logging in fred:
>
> - Readability and code clutter, which was my original questioning;
> - Raw throughput, as raised by toad.
>
> Point 1 could mostly be solved by removing any traces of
On Thursday 22 Mar 2012 05:50:48 David ?Bombe? Roden wrote:
> On Tue, 2012-03-20 at 22:44 +, Matthew Toseland wrote:
>
> > I am speaking from experience. write() is supposed to either succeed or
> > throw. PrintWriter busy-loops on disk full when stderr is redirected to a
> > file. Feel
On 22-03-2012 08:50, Matthew Toseland wrote:
> On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
>> There are basically two big concerns regarding logging in fred:
>>
>> - Readability and code clutter, which was my original questioning;
>> - Raw throughput, as raised by toad.
>>
>> Point 1
On Tue, 2012-03-20 at 22:44 +, Matthew Toseland wrote:
> I am speaking from experience. write() is supposed to either succeed or
> throw. PrintWriter busy-loops on disk full when stderr is redirected to a
> file. Feel free to test it, it may be that it doesn't happen with modern
> JVMs.
On Thursday 22 Mar 2012 05:50:48 David ‘Bombe’ Roden wrote:
On Tue, 2012-03-20 at 22:44 +, Matthew Toseland wrote:
I am speaking from experience. write() is supposed to either succeed or
throw. PrintWriter busy-loops on disk full when stderr is redirected to a
file. Feel free to
On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
There are basically two big concerns regarding logging in fred:
- Readability and code clutter, which was my original questioning;
- Raw throughput, as raised by toad.
Point 1 could mostly be solved by removing any traces of logMINOR
On 22-03-2012 08:50, Matthew Toseland wrote:
On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
There are basically two big concerns regarding logging in fred:
- Readability and code clutter, which was my original questioning;
- Raw throughput, as raised by toad.
Point 1 could mostly be
Lazy evaluation is trivial.
Log.info({1} did {2},
new Object(){ public String toString() { return ITEM_1; } },
new Object(){ public String toString() { return ITEM_2; } }
);
Garbage collection with short-lived objects costs next to nothing.
On 22/03/12 21:15, Zlatin Balevsky wrote:
Double-digit millisecond pauses are not nothing. They may be acceptable
right now but unless you can offer a drastically cleaner syntax Fred should
stick with predicates as they are handled much better by the hotspot jit.
On Mar 22, 2012 5:36 PM, Ximin Luo infini...@gmx.com wrote:
Lazy
My claim is based on day-to-day observations of hundreds of JVMs under
various load scenarios.
Your claim that modern JVMs do escape analysis is worthless as it shows
that you have merely read some blog posts, and even those you've read only
partially. Please point to the exact lines of code in
The example you provide is fast because it does not do any object
allocation. Please don't take my word for it - download (or better
yet, build one yourself) a fastdebug build from openjdk.org and look
at the opto-assembly that gets generated when you pass the
-XX:+PrintOptoAssembly switch.
LOL, are you kidding me?
Please point to the exact lines of code that results in double-digit
millisecond pauses?
Talk is cheap, show us some numbers.
BTW, the example I gave is not real code, and contains no variable
declarations, so your challenge makes no sense. Since you apparently didn't
There are basically two big concerns regarding logging in fred:
- Readability and code clutter, which was my original questioning;
- Raw throughput, as raised by toad.
Point 1 could mostly be solved by removing any traces of logMINOR and
logDEBUG on all but the few places where generating
Is there a good reason to roll our own logging framework? What about
http://www.slf4j.org/ or one of the many other alternatives?
Ian.
On Sun, Mar 18, 2012 at 6:40 PM, Marco Schulze wrote:
> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> and the mess that logging is
Is there a good reason to roll our own logging framework? What about
http://www.slf4j.org/ or one of the many other alternatives?
Ian.
On Sun, Mar 18, 2012 at 6:40 PM, Marco Schulze marco.c.schu...@gmail.comwrote:
One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
and
There are basically two big concerns regarding logging in fred:
- Readability and code clutter, which was my original questioning;
- Raw throughput, as raised by toad.
Point 1 could mostly be solved by removing any traces of logMINOR and
logDEBUG on all but the few places where generating
On Monday 19 Mar 2012 21:56:42 Marco Schulze wrote:
> On 19-03-2012 16:42, Matthew Toseland wrote:
> > No it doesn't. We need to be able to filter *by class name*, not just
> > globally. I agree that in theory the if(logMINOR) is optional if the
> > message is static though; I guess the JVM is
On Monday 19 Mar 2012 22:37:05 Marco Schulze wrote:
> On 19-03-2012 18:56, Marco Schulze wrote:
> > On 19-03-2012 16:42, Matthew Toseland wrote:
> >> PrintWriter (System.err) busy-loops. :( It is probably possible to
> >> get the underlying OutputStream though.
> > Will take a look at it.
> From
On normal conditions, never. My reasoning was way off... streams are
finalized (and flushed) even on abnormal exit.
On 20-03-2012 05:09, Martin Nyhus wrote:
> On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
>> How often does what happen?
> Crashes that cause the log buffer to be lost
On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
> How often does what happen?
Crashes that cause the log buffer to be lost before it is written to disk and
whatever else you had in mind when you wrote this:
On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the
On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the reason every thread should wait. If the log is
> always flushed and fred crashes, you know exactly where the last good
> checkpoint was before the crash. If the log is buffered (or
> asynchronous), the thread may be
On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
How often does what happen?
Crashes that cause the log buffer to be lost before it is written to disk and
whatever else you had in mind when you wrote this:
On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
Synchronization is the
On normal conditions, never. My reasoning was way off... streams are
finalized (and flushed) even on abnormal exit.
On 20-03-2012 05:09, Martin Nyhus wrote:
On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
How often does what happen?
Crashes that cause the log buffer to be lost before
On Monday 19 Mar 2012 22:37:05 Marco Schulze wrote:
On 19-03-2012 18:56, Marco Schulze wrote:
On 19-03-2012 16:42, Matthew Toseland wrote:
PrintWriter (System.err) busy-loops. :( It is probably possible to
get the underlying OutputStream though.
Will take a look at it.
From what I
On Monday 19 Mar 2012 21:56:42 Marco Schulze wrote:
On 19-03-2012 16:42, Matthew Toseland wrote:
No it doesn't. We need to be able to filter *by class name*, not just
globally. I agree that in theory the if(logMINOR) is optional if the
message is static though; I guess the JVM is fast
How often does what happen?
On 19-03-2012 20:21, Martin Nyhus wrote:
> On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
>> Synchronization is the reason every thread should wait. If the log is
>> always flushed and fred crashes, you know exactly where the last good
>> checkpoint was before
Never worked with aspects. Could you provide some snippets?
On 19-03-2012 09:52, Nicolas Hernandez wrote:
> Hello,
>
> It is really difficult to have a complete log system working. One
> solution is to use aspects.
>
> Is this a good idea ?
>
> - Nicolas Hernandez
> a-n - aleph-networks
>
On Monday 19 Mar 2012 12:17:51 Marco Schulze wrote:
> On 18-03-2012 21:50, Matthew Toseland wrote:
> > On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
> >> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> >> and the mess that logging is inside fred. I've written a
On 19-03-2012 18:56, Marco Schulze wrote:
> On 19-03-2012 16:42, Matthew Toseland wrote:
>> PrintWriter (System.err) busy-loops. :( It is probably possible to
>> get the underlying OutputStream though.
> Will take a look at it.
From what I found after a quick googling, full disk errors do throw
On 19-03-2012 16:42, Matthew Toseland wrote:
> No it doesn't. We need to be able to filter *by class name*, not just
> globally. I agree that in theory the if(logMINOR) is optional if the message
> is static though; I guess the JVM is fast enough that this won't cost us any
> cycles?
>
>
Hello,
It is really difficult to have a complete log system working. One solution
is to use aspects.
Is this a good idea ?
- Nicolas Hernandez
a-n - aleph-networks
*associ?*
http://www.aleph-networks.com
On Mon, Mar 19, 2012 at 12:40 AM, Marco Schulze
wrote:
> One thing has been bothering
On 18-03-2012 21:50, Matthew Toseland wrote:
> On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
>> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
>> and the mess that logging is inside fred. I've written a very simple
>> replacement for Logger + associated classes with
On Monday 19 Mar 2012 00:50:33 Matthew Toseland wrote:
> On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
...
> > - No logging method accepts an Object parameter - hashCode() is not
> > exactly useful.
>
> We're not after the hashcode, we're after the class name. We need to be able
> to
On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> and the mess that logging is inside fred. I've written a very simple
> replacement for Logger + associated classes with the following changes:
You're not using the
Hello,
It is really difficult to have a complete log system working. One solution
is to use aspects.
Is this a good idea ?
- Nicolas Hernandez
a-n - aleph-networks
*associé*
http://www.aleph-networks.com
On Mon, Mar 19, 2012 at 12:40 AM, Marco Schulze
marco.c.schu...@gmail.comwrote:
One
1 - 100 of 106 matches
Mail list logo
