Hi,
On 19/08/14 16:00, Jason Mehrens wrote:
Stanimir,
Looks like the int overflow on the metered stream is an issue that hasn't been
tracked. The other issues have been reported under
https://bugs.openjdk.java.net/browse/JDK-6433253
and https://bugs.openjdk.java.net/browse/JDK-8028786
Apologies for not reacting sooner.
Thanks for looking at the history Jason ;-)
I have logged https://bugs.openjdk.java.net/browse/JDK-8059767,
and will probably close the other two as duplicates.
I usually prefer to keep different problems separate but in this
case it's probably more efficient to fix these three in one go...
best regards,
-- daniel
Jason
----------------------------------------
Date: Tue, 19 Aug 2014 11:06:27 +0300
Subject: java.util.logging.FileHandler integer overflow prevents file rotation
From: stani...@riflexo.com
To: core-libs-dev@openjdk.java.net
java.util.logging.FileHandler uses ints to track the written bytes
that can cause negative value for
java.util.logging.FileHandler.MeteredStream.written as there is no
check in any of the write methods.
The overflow prevents the check in FileHandler.publish(LogRecord)
meter.written>= limit to ever trigger, esp. setting limit to
Integer.MAX_VALUE that effectively always prevents file rotation.
On a flip note, MeteredStream should be a static class.
On another flip note, FileHandler should be using long as part of the
API and internal implementation. ints are limited to 2GiB even when
properly implemented that's a relatively low amount for certain types
of logging files. So I propose adding overloaded c-tors
FileHandler(String pattern, long limit, int count, boolean append)
and FileHandler(String pattern, long limit, int count). LogManager
should have a method "long getLongProperty(String name, long
defaultValue)" to initialize limit.
Thanks
Stanimir
