so even a bufferSize of 0 doesn't flush, and that is because the
StreamEncoder has a non configurable buffering mechanism (instantiated
through the OutputStreamWriter) and has nothing to do with buffering we
implemented.
setting -1 leads to direct flushing as expected.
Filip
On 01/13/2010
Author: jim
Date: Wed Jan 13 13:28:54 2010
New Revision: 898745
URL: http://svn.apache.org/viewvc?rev=898745view=rev
Log:
Merge r897380, r897381 from trunk:
Followup for r816252/r891328
Allow to disable buffering in JULI FileHandler
The previous implementation did not work as expected because of
-1, I would propose this one to be
writer.write(result);
if (bufferSize 0)
flush();
Here is why
1. No synchronized(this) - not sure why we think its needed
2. It allows a setting of bufferSize==0 - use system default
3. bufferSize0 do a flush of the writer
best
Filip
On 01/13/2010
2010/1/13 Filip Hanik - Dev Lists devli...@hanik.com:
-1, I would propose this one to be
writer.write(result);
if (bufferSize 0)
flush();
Here is why
1. No synchronized(this) - not sure why we think its needed
Re: synchronized(this)
-writer.write(result);
+
On 13/01/2010 16:24, Konstantin Kolinko wrote:
There is Mark's patch for that (r898468), but I have doubts
regarding Runtime.getRuntime().addShutdownHook(new Cleaner());
used there.
Why? It is pretty much identical to the code in the standard LogManager.
We could disable log buffering in
On 01/13/2010 09:24 AM, Konstantin Kolinko wrote:
2010/1/13 Filip Hanik - Dev Listsdevli...@hanik.com:
-1, I would propose this one to be
writer.write(result);
if (bufferSize 0)
flush();
Here is why
1. No synchronized(this) - not sure why we think its needed
Re:
2010/1/13 Mark Thomas ma...@apache.org:
On 13/01/2010 16:24, Konstantin Kolinko wrote:
There is Mark's patch for that (r898468), but I have doubts
regarding Runtime.getRuntime().addShutdownHook(new Cleaner());
used there.
Why? It is pretty much identical to the code in the standard
