Hi,
This is a trivial fix to replace a wrong @bug id
in TestRootLoggerLevel.java:
https://bugs.openjdk.java.net/browse/JDK-8026952
I mistakenly put 8023163 (which I was investigating) instead of
8026499 (which is what I was actually fixing).
-- daniel
$ hg diff
diff -r 41dcb0c2e194
Changeset: 30a3aefc4084
Author:dfuchs
Date: 2013-11-13 10:50 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30a3aefc4084
8026952: Test
java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has
wrong @bug id
Summary: Trivial: change @bug 8023163 into
Hi Mandy,
looks good!
-- daniel
On 11/12/13 8:29 PM, Mandy Chung wrote:
This is a simple code deletion in sun.misc.JavaAWTAccess and its
implementation class:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/
This patch removes the methods from
Hi Joe,
The new webrev looks good...
-- daniel
On 11/13/13 11:08 PM, huizhe wang wrote:
On 11/13/2013 1:33 PM, Alan Bateman wrote:
On 13/11/2013 20:02, huizhe wang wrote:
Hi,
The issue is that the limits applied to each processing process
rather than each file processing. This applies to
Hi,
Please find below a webrev for:
8028185: XMLFormatter.format emits incorrect year
https://bugs.openjdk.java.net/browse/JDK-8028185
The fix is trivial:
http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/
best regards,
-- daniel
Hi Rob,
May I suggest changing System.out.println in Basic.fail into
System.err.println? Or possibly printing the message on both
out and err?
This would ensure that the error message appears on System err before
the stack trace - which might be better for diagnosis.
-- daniel
On 11/19/13
On 11/19/13 6:40 PM, Mandy Chung wrote:
On 11/19/13 2:23 AM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8028185: XMLFormatter.format emits incorrect year
https://bugs.openjdk.java.net/browse/JDK-8028185
The fix is trivial:
http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev
Changeset: 67d742c75971
Author:dfuchs
Date: 2013-11-19 20:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67d742c75971
8028185: XMLFormatter.format emits incorrect year
Summary: Fixes a regression where the year in the date was increased by 1900.
Reviewed-by: alanb, mchung
Hi,
Please find below a fix for:
8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10
This bug complains that java/util/logging/CheckLockLocationTest.java
has been seen failing on a solaris 10 machine, with message:
java.lang.RuntimeException: Test failed: should not have
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful to print the owner of the directory in case
Hi,
I have modified the test to print the user name as well:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.01/
-- daniel
On 11/19/13 9:26 PM, Mandy Chung wrote:
On 11/19/2013 12:12 PM, Daniel Fuchs wrote:
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel
Changeset: 059530c5ae9a
Author:dfuchs
Date: 2013-11-19 22:28 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/059530c5ae9a
8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10
Summary: this test has been seen failing on Solaris 10, presumably because it
was
On 11/21/13 4:58 AM, Patrick Zhang wrote:
Hi Everyone,
I am working on https://bugs.openjdk.java.net/browse/JDK-8027973. The
problem is caused by wrong URL format on windows. file://c:\xxx is one
invalid schema.
Solution:
Replace file:// with file:/// then it will work on windows and it
will
On 11/26/13 11:13 PM, huizhe wang wrote:
On 11/26/2013 1:37 PM, Alan Bateman wrote:
On 26/11/2013 18:38, huizhe wang wrote:
Hi all,
Here's revised webrev, as Alan suggested, including the implementation.
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/
So is this handling
Hi,
Please find below a webrev for:
8029281: Synchronization issues in Logger and LogManager
https://bugs.openjdk.java.net/browse/JDK-8029281:
I believe this changeset will also fix JDK-8027670 and
JDK-8029092 - which I have thus closed as duplicates of JDK-8029281.
webrev:
for today. Will check the rest of patch tomorrow.
Regards, Peter
On 11/27/2013 08:23 PM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8029281: Synchronization issues in Logger and LogManager
https://bugs.openjdk.java.net/browse/JDK-8029281:
I believe this changeset will also fix JDK
Hi Shi Jun Zhang,
I agree with Peter.
It is strange that CustomFormatter calls Logger.log. This looks like
the source of the deadlock.
The Logger API can be customized in many ways - and when you can
plugin custom classes and objects you can introduce new opportunity
for deadlocks.
Concerning
On 11/29/13 7:19 AM, Shi Jun Zhang wrote:
On 11/29/2013 1:21 AM, Daniel Fuchs wrote:
Hi Shi Jun Zhang,
I agree with Peter.
It is strange that CustomFormatter calls Logger.log. This looks like
the source of the deadlock.
Hi Daniel,
I explained why we call Logger.log in CustomerFormatter
On 11/29/13 10:49 AM, Shi Jun Zhang wrote:
On 11/29/2013 5:25 PM, Daniel Fuchs wrote:
On 11/29/13 7:19 AM, Shi Jun Zhang wrote:
On 11/29/2013 1:21 AM, Daniel Fuchs wrote:
Hi Shi Jun Zhang,
I agree with Peter.
It is strange that CustomFormatter calls Logger.log. This looks like
the source
On 11/28/13 3:26 PM, Daniel Fuchs wrote:
On 11/27/13 10:34 PM, Peter Levart wrote:
Hi Daniel,
I have started looking at the LogManager change first, and here's the
1st race I found...
Hi Peter,
Thanks a lot for your feedback! see below...
The new method LoggerWeakRef.dispose() can
Hi Mark,
Using a CountDownLatch looks like the right thing to do
indeed.
At first I thought that the instance variables would need
to be declared volatile - or synchronized - but since they're
set before the new Thread is created and not changed afterwards
I guess it's OK.
It's a bit strange to
On 11/29/13 4:56 PM, Alan Bateman wrote:
On 29/11/2013 10:08, Daniel Fuchs wrote:
However, removing or just moving the lock around might well introduce new
unknown issues - so it will need to be carefully anaIyzed, and I am
not sure
it can/should be attempted in a minor JDK release.
Yes, we
On 11/29/13 5:19 PM, Alan Bateman wrote:
On 29/11/2013 14:21, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8025211/webrev/
which address the issue raised in the bug
https://bugs.openjdk.java.net/browse/JDK-8025211
an intermittent
machine with consistent success.
regards
Mark
On 29/11/2013 16:41, Daniel Fuchs wrote:
On 11/29/13 5:19 PM, Alan Bateman wrote:
On 29/11/2013 14:21, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8025211/webrev/
which address the issue
then it would be if you created and called
a hypothetical disposeFromParent() which only took care of unlinking
from parent logger...
Regards, Peter
On 11/29/2013 12:41 PM, Daniel Fuchs wrote:
Hi,
Here is a new revision that includes Peter's findings.
Thanks again for that Peter!
http
Hi Mandy,
I have updated the webrev taking your comments into account.
http://cr.openjdk.java.net/~dfuchs/webrev_8029281/webrev.02/
Changes are small and outlined below:
On 12/3/13 1:49 AM, Mandy Chung wrote:
On 11/29/2013 3:41 AM, Daniel Fuchs wrote:
Hi,
Here is a new revision
Changeset: 9f624e115c6b
Author:dfuchs
Date: 2013-12-04 01:58 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f624e115c6b
8029281: Synchronization issues in Logger and LogManager
Summary: Fixes several race conditions in logging which have been at the root
cause of
On 12/9/13 9:58 AM, Peter Levart wrote:
On 12/09/2013 09:51 AM, Shi Jun Zhang wrote:
On 12/9/2013 4:28 PM, Peter Levart wrote:
On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
Peter,
I think you are misunderstanding this problem. This deadlock is not
related to the formatter synchronization, we
Hi Peter,
I had a look at your later webrev 03 and it looks like a good
solution to fix the issue. I am glad to see the sealed
variable removed.
About using lambda I don't know whether we have guidelines
for that - in this case it certainly makes the code more
concise. It is good to remember
On 12/11/13 8:52 PM, huizhe wang wrote:
Hi,
This is a quick documentation change to fix an error in
javax.xml.stream.XMLOutputFactory:
http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/
Thanks,
Joe
Hi Joe,
Looks good to me - but I'm not a native English speaker :-)
-- daniel
On 12/16/13 10:14 PM, Mandy Chung wrote:
On 12/14/2013 9:38 AM, Peter Levart wrote:
Hi,
Daniel reminded me of a couple of issues the 4th revision of the patch
would have when backporting to 7u. So here's another variant that
tries to be more backport-friendly:
Hi,
Please find below a fix for what I believe is a test bug.
I plan to push this in JDK 9 dev.
https://bugs.openjdk.java.net/browse/JDK-8030187
This seems to be a very intermittent failure.
It looks as if a logger held in a local variable can be
arbitrarily garbage collected if that variable
Hi Joe,
The fix looks good - though I wonder at whether incrementing
whiteSpaceLookup by a fix amount wouldn't be better than
doubling its length.
best regards,
-- daniel
On 12/16/13 8:31 PM, huizhe wang wrote:
Hi,
This is a quick fix for a whitespace buffer that was not adjusted
properly
On 12/17/13 6:02 PM, Peter Levart wrote:
On 12/17/2013 05:26 PM, Mandy Chung wrote:
This is a good point. The patch for JDK 8 and above uses limited
doPrivileged that only grants LoggingPermission(control) access even
though the system class has all permissions and it should be no
difference
On 12/18/13 12:55 AM, Peter Levart wrote:
On 12/17/2013 11:02 PM, Daniel Fuchs wrote:
On 12/17/13 6:02 PM, Peter Levart wrote:
On 12/17/2013 05:26 PM, Mandy Chung wrote:
This is a good point. The patch for JDK 8 and above uses limited
doPrivileged that only grants LoggingPermission(control
Hi
Please find below a fix for:
8030192 - [TEST_BUG] java/util/logging/TestLoggerBundleSync.java
failed with NPE
https://bugs.openjdk.java.net/browse/JDK-8030192
http://cr.openjdk.java.net/~dfuchs/webrev_8030192/webrev.00/
There were two issues in the test:
1. The message that
On 12/18/13 9:35 PM, Mandy Chung wrote:
On 12/17/2013 3:57 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for what I believe is a test bug.
I plan to push this in JDK 9 dev.
https://bugs.openjdk.java.net/browse/JDK-8030187
This seems to be a very intermittent failure.
It looks
Hi Paul,
I looked at the modifications in java.util.logging and they
look both sensible and desirable.
Had to look at the code for Objects.toString(Object,Object) as
I had never used that before :-)
Thanks for taking care of that,
-- daniel
On 12/19/13 3:51 PM, Paul Sandoz wrote:
Hi,
Here
Hi Peter,
Good idea to add a package constructor in Handler.
It looks much cleaner than the configure method.
Good tests too - thanks for adding that!
To access files with JPRT there is a simpler manner (though what
you have looks good).
JPRT sets a system property test.src which point at the
Hi,
Please find below a fix for
8030850: Setting .level=FINEST for the root logger in
logging configuration file doesn't work
https://bugs.openjdk.java.net/browse/JDK-8030850
http://cr.openjdk.java.net/~dfuchs/webrev_8030850/webrev.00/
This is a regression I introduced with my fix
Changeset: d77a1c9fd5b8
Author:dfuchs
Date: 2013-12-22 11:20 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d77a1c9fd5b8
8030850: Setting .level=FINEST in logging configuration file doesn't work
Summary: setLevel(INFO) was called too early on root logger, causing the value
- or remove that call to
System.gc() altogether?
This was just a means of triggering 8031068 and making the test
fail more consistently (it just validates that this is the
right fix for 8031068).
-- daniel
-Chris
On 8 Jan 2014, at 17:34, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi,
Please
/~dfuchs/webrev_8031068-jdk9/webrev.01/
best regards,
-- daniel
-Chris
On 8 Jan 2014, at 17:34, Daniel Fuchs daniel.fu...@oracle.com wrote:
Hi,
Please find below a patch for a test bug:
8031068: java/util/logging/ParentLoggersTest.java:
checkLoggers: getLoggerNames() returned unexpected
On 1/9/14 7:38 PM, Mandy Chung wrote:
On 1/9/2014 10:18 AM, Daniel Fuchs wrote:
OK - I removed the unnecessary calls.
http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.02/
Thumbs up! Thanks for the update.
You have fixed a few test failures of this issue. Do you know
Hi,
Please find below a trivial fix for
8031525: Logger created in test/tools/jar/UpdateManifest.java might
get gc'ed too early.
https://bugs.openjdk.java.net/browse/JDK-8031525
Hopefully that's the last of its kind - (see
https://bugs.openjdk.java.net/browse/JDK-8029595).
webrev:
COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -28,7 +28,7 @@
*
* @author Daniel Fuchs
*
- * @run compile -XDignore.symbol.file=true -source 1.6 -g
LocalRMIServerSocketFactoryTest.java
+ * @run compile
Hi,
Please find below a webrev for:
8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281
https://bugs.openjdk.java.net/browse/JDK-8031980
http://cr.openjdk.java.net/~dfuchs/webrev_8031980/webrev.00/
Thread dumps that were sent to me after recent sighting of
JDK-8027670 have
On 1/20/14 7:17 PM, Mandy Chung wrote:
On 1/17/2014 6:51 AM, Daniel Fuchs wrote:
Hi,
Please find below a webrev for:
8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281
https://bugs.openjdk.java.net/browse/JDK-8031980
http://cr.openjdk.java.net/~dfuchs/webrev_8031980/webrev
Hi,
It looks fine to me Joe.
best regards,
-- daniel
On 1/24/14 9:31 PM, huizhe wang wrote:
Hi,
Please review a javadoc change to javax.xml.stream factories. This
change makes it clear that the two args ServiceLoader#load method is
used when the specified classLoader is not null.
Hi Stuart,
I wonder whether you should replace the assert in the
constructor by an explicit null check:
- assert systemStub != null
+ if (systemStub == null) throw new NullPointerException();
The reason I see is that before your change, an object constructed
with a null systemStub would have
Hi,
Please find below a fix [1] for:
8033542: test/java/util/logging/SimpleLogManager might let
Loggers be gc'ed too early. [2]
[1] http://cr.openjdk.java.net/~dfuchs/webrev_8033542/webrev.00
[2] https://bugs.openjdk.java.net/browse/JDK-8033542
The issue is that some of the loggers
Hi,
Please find below a patch that adds a new test for logging
in JDK 9.
The test verifies an issue we had on JDK 7 (the test is already
in 7) but since the issue was not present in 8 9 the fix
(and test) went to 7 only.
This bug is about adding the same test that was added to 7 to
9 (and
On 2/6/14 4:49 PM, Mandy Chung wrote:
Hi Daniel,
On 2/6/2014 7:29 AM, Daniel Fuchs wrote:
https://bugs.openjdk.java.net/browse/JDK-8029876
8029876: Add a test to verify that Logger.getLogger
LogManager.getLogManager don't throw NPE
when System.out == null
webrev (trivial
On 2/11/14 5:55 PM, Lance @ Oracle wrote:
Hi joe
It looks like you changed the serialversionuid in Durationimpl, did it get
changed incorrectly previously?
I noticed that as well, but I'm not sure it matters since Duration
uses writeReplace to serialize itself as an instance of
On 2/12/14 2:19 PM, Alan Bateman wrote:
I need a reviewer for a trivial change to remove a tiny number of unused
imports. The motive is experimental compilation of the JDK as modules
rather than one big compilation unit. I've no doubt that there is other
code that has unused imports but it's
Hi Joe,
Couldn't all the new orig_* fields in XMLGregorianCalendarImpl be
made transient?
It looks as if they shouldn't be serialized anyway. Should they?
Not making them transient would change the serialization form, and
I'm not sure where that would take us...
best regards,
-- daniel
On
Hi Lance,
Looks good,
-- daniel
On 2/13/14 8:59 PM, Lance Andersen wrote:
Hi all,
Need a reviewer for this trivial change to remove the redundant the resources
from Clob.free.
I will be going through all of the java[x]/sql classes at a later time to clean up the use
of code/code so I did
Hi Roger,
I agree with Paul that using Objects.toString(environment) would be
cleaner.
Concerning the test, you may want to modify CheckHandler.publish to
filter out any log record that doesn't come from your ProcessImpl
classes. Something like:
175 @Override
176 public void
Hi Joe,
Sorry for the late reply...
On 2/14/14 6:35 PM, huizhe wang wrote:
Hi All,
I added a SerializationTest. The test contains a helper that can
generate serialization files for XMLGregorianCalendar and Duration. I've
created such files for jdk6,7,8 and 9, and manually run the test, that
,
-- daniel
Thanks,
Joe
On 2/17/2014 8:23 AM, Daniel Fuchs wrote:
Hi Joe,
Sorry for the late reply...
On 2/14/14 6:35 PM, huizhe wang wrote:
Hi All,
I added a SerializationTest. The test contains a helper that can
generate serialization files for XMLGregorianCalendar and Duration. I've
created
PM, huizhe wang wrote:
On 2/18/2014 3:39 AM, Daniel Fuchs wrote:
On 2/17/14 11:17 PM, huizhe wang wrote:
Thanks Daniel.
I updated the test to call class.getResourceAsStream (see fromFile
method) instead at the runtime. The filePath now is only used for the
helper method to generate test file
On 2/20/14 7:44 PM, huizhe wang wrote:
Hi Aleksej,
The change looks good. It's good to consolidate test cases into a single
test for each encoding.
Looks good!
-- daniel
Thanks,
Joe
On 2/20/2014 6:54 AM, Aleksej Efimov wrote:
Hi,
There is a problem in XSLT string-length function:
When
Hi,
Please find below a trivial fix for [1]:
8036916: Deprecation warnings in LogManager
[1] https://bugs.openjdk.java.net/browse/JDK-8036916
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00/
best regards,
-- daniel
On 3/12/14 7:34 PM, Mandy Chung wrote:
On 3/12/2014 11:27 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial fix for [1]:
8036916: Deprecation warnings in LogManager
[1] https://bugs.openjdk.java.net/browse/JDK-8036916
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8036916/webrev.00
Hi guys,
While playing with JDK 9 javadoc command I noticed that it
seems to treat all single method interfaces as if they were
functional interfaces - even though they don't have the
@FunctionalInterface annotation.
For instance - I did 'make docs' - and I'm seeing this text
in the javadoc for
Hi Alexander,
Looks good.
I think I would remove the leading p in
http://cr.openjdk.java.net/~yan/8038795/webrev.00/src/share/classes/javax/management/remote/JMXPrincipal.java.frames.html
as well. If you don't please check that the generated javadoc for
JMXPrincipal.java still looks good.
tidy happy.
Thanks,
Alexander
On 01.04.2014 17:44, Daniel Fuchs wrote:
Hi Alexander,
Looks good.
I think I would remove the leading p in
http://cr.openjdk.java.net/~yan/8038795/webrev.00/src/share/classes/javax/management/remote/JMXPrincipal.java.frames.html
as well. If you don't please check
On 4/2/14 8:39 AM, Joe Darcy wrote:
Hello,
*fingers crossed* The patch below should be the last change needed to
fully clear the JDK 9 jdk repo of serialization warnings.
Looks good Joe!
best regards,
-- daniel
Thanks,
-Joe
diff -r b6997dd0667e
Looks good Ivan!
best,
-- daniel
On 4/14/14 1:36 PM, Ivan Gerasimov wrote:
Hello!
It was reported that the error message in an exception is missing a space.
Grep found a couple of other places with the same misformatting.
Can I please have a review of the trivial fix?
BUGURL:
Hi guys,
Should 'actual' and 'reference' be declared as volatile?
I see that they are accessed from main() after joining the threads.
Or does joining the threads guarantees that 'main' will see the right
values?
best regards,
-- daniel
On 4/15/14 8:48 AM, David Holmes wrote:
On
I Seán,
I wonder whether it would be better to use a ConcurrentHashMap in
place of the plain HashMap and remove the synchronized lock
around putIfAbsent/computeIfAbsent?
best regards,
-- daniel
On 5/11/14 10:56 PM, Seán Coffey wrote:
Now that JDK 8 is the official build bootstrap JDK for JDK
Hi Mark,
AFAIKS computeIfAbsent does what we want:
http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#computeIfAbsent-K-java.util.function.Function-
It seems that putIfAbsent would not though. This is indeed confusing.
I wish putIfAbsent had been specified similarly to
Hi Paul,
I looked at -management and the changes there look good.
There is just some two spaces vs four space formatting in
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java.frames.html
line 99.
Hi Joe,
Looks good!
-- daniel
On 6/11/14 5:54 PM, huizhe wang wrote:
Fix some typos in the JAXP documentation. Please review.
http://cr.openjdk.java.net/~joehw/jdk9/8046443/webrev/
Thanks,
Joe
Hi Joe,
Thanks for the detailed explanation.
It really helps reviewing the fix!
This looks reasonable to me. One minor nit is that you
could turn:
769 BigInteger maxintAsBigInteger = BigInteger.valueOf((long)
Integer.MAX_VALUE);
into a static final constant in the class.
best
Thanks Joe!
This is much cleaner indeed :-)
-- daniel
On 6/21/14 4:36 AM, huizhe wang wrote:
Thanks Daniel, Lance.
On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
Hi Joe,
Thanks for the detailed explanation.
It really helps reviewing the fix!
Glad to know it helps. I thought this part of spec
Hi Jason,
Looking at the diff for 6244047 - I see that, as you pointed
out, the unwanted behavior described comes from the fact that
the new code is using CREATE_NEW - which prevents the 'zombie
lock files' from being reused.
I am not an expert in file locks - but I wonder whether we
could
Hi Jason,
On 6/23/14 2:51 PM, Jason Mehrens wrote:
Daniel,
My understanding is that changing CREATE_NEW to use CREATE would make it work
like does in JDK7. Closing the lock files when the FileHandler is unreferenced
I is probably the fix for JDK-6774110: lock file is not deleted when child
) {
// We got the lock. Remember it.
On 6/23/14 3:18 PM, Daniel Fuchs wrote:
Hi Jason,
On 6/23/14 2:51 PM, Jason Mehrens wrote:
Daniel,
My understanding is that changing CREATE_NEW to use CREATE would make
it work like does in JDK7. Closing the lock files when the
FileHandler
On 6/23/14 4:53 PM, Alan Bateman wrote:
On 23/06/2014 10:48, Daniel Fuchs wrote:
:
All in all - I feel our best options would be to revert to using
CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
and live with the issue.
Hopefully some nio experts will chime
@openjdk.java.net
Subject: Re: Zombie FileHandler locks can exhaust all available log file locks.
On 6/23/14 4:53 PM, Alan Bateman wrote:
On 23/06/2014 10:48, Daniel Fuchs wrote:
:
All in all - I feel our best options would be to revert to using
CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
On 6/25/14 2:34 PM, Jason Mehrens wrote:
Daniel,
FileChannel.open(WRITE,APPEND) could throw NoSuchFileException during a startup
and shutdown race between two VMs. That case needs to either perform a bounded
retry or continue and rotate.
Hi Jason, Alan,
Here is an updated version of the
On 7/4/14 12:21 PM, Evgeniya Stepanova wrote:
Daniel, you are right. Test fail on jre
Test removed from needs_jre group and added to the needs_jdk one
New diff attached
Thank you!
The new diff looks good!
-- daniel
On 04.07.2014 13:57, Daniel Fuchs wrote:
Hi Evgeniya,
This looks OK
On 7/4/14 6:35 PM, Alan Bateman wrote:
On 01/07/2014 10:25, Daniel Fuchs wrote:
Hi Jason, Alan,
Here is an updated version of the fix that does a bounded
retry (retries once - and if it fails, proceeds with the next
name). I have also added NO_FOLLOW_LINKS - for the case where
we try to open
On 7/4/14 7:58 PM, Alan Bateman wrote:
On 04/07/2014 18:25, Daniel Fuchs wrote:
Given that nothing is going to be written to the file then maybe I
don't need APPEND.
I just don't want the call to FileChannel.open() to truncate the file.
APPEND should be harmless here, just not needed
Thanks Alan!
Just for the record the 'final' webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.02
I will push this shortly...
-- daniel
On 7/4/14 8:24 PM, Alan Bateman wrote:
On 04/07/2014 19:10, Daniel Fuchs wrote:
hmmm. yes - you're right. I should catch
Hi,
Please find below a fix for
8048913: java/util/logging/LoggingDeadlock2.java times out
http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/
jdk/test/java/util/logging/LoggingDeadlock2.java has been seen failing
in timeout in some of our internal nightly builds.
Hi Mandy,
On 7/8/14 4:59 PM, Mandy Chung wrote:
I took out the special case for javax.jnlp and follow up the change in
deploy to use @jdk.Exported to indicate its supportedness. I also added
a new test case to check the dot file output:
On 7/9/14 5:46 AM, Mandy Chung wrote:
On 7/8/2014 5:58 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for
8048913: java/util/logging/LoggingDeadlock2.java times out
http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/
My suggestion is thus simply to remove the /timeout
On 7/15/14 9:35 AM, Paul Sandoz wrote:
Ping..
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027508.html
Paul.
Hi Paul,
This is not my area of expertise - but I haven't seen anything wrong.
However - I applied your patch and ran the tests locally on my
machine, and I saw
Hi Mandy,
here is a typical output - with names mangled to save
space:
s.u.l.p.LPA (rt.jar)
- s.s.a.GP JDK internal API (Use j.s.PA @since 1.1)
- s.u.c.CLDRLPA JDK internal API (rt.jar)
In the first dependency line, the archive name has been replaced
by the 'Use ...' message.
I
.
thanks
Mandy
On 7/16/2014 6:10 AM, Daniel Fuchs wrote:
Hi Mandy,
here is a typical output - with names mangled to save
space:
s.u.l.p.LPA (rt.jar)
- s.s.a.GP JDK internal API (Use j.s.PA @since 1.1)
- s.u.c.CLDRLPA JDK internal API (rt.jar)
In the first dependency line, the archive
Hi,
Please find below a fix for:
8054480: Test java/util/logging/TestLoggerBundleSync.java fails:
Unexpected bundle name: null
This test has been reported to fail from time to time with the
following stack:
java.lang.RuntimeException: Unexpected bundle name: null
at
Please find below a fix for
8052403: java/util/logging/CheckZombieLockTest.java fails
with NoSuchFileException
https://bugs.openjdk.java.net/browse/JDK-8052403
The issue here is that CheckZombieLockTest and CheckLockLocationTest use
(create and delete) the same writable-dir under /tmp.
On 8/14/14 10:02 AM, Wang Weijun wrote:
I am looking at 8054896: Loading a KeyStore prevents GC of Classloader and am
now able to reproduce it on my system. I do see the webapp-related classes present in a
heapdump created by VisualVM but not sure what the next steps should be to tell why they
://cr.openjdk.java.net/~dfuchs/webrev_8052403/webrev.01/
(no need to re-review it's mostly noise due to the added white
spaces now).
best regards,
-- daniel
Mandy
On 8/13/2014 5:43 AM, Daniel Fuchs wrote:
Please find below a fix for
8052403: java/util/logging/CheckZombieLockTest.java fails
Hi,
Please find below a proposed patch for
8043306 - Provide a replacement for the API that allowed to listen
for LogManager configuration changes
https://bugs.openjdk.java.net/browse/JDK-8043306
Proposed Patch:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
On 9/10/14 1:25 PM, Alan Bateman wrote:
On 10/09/2014 10:49, Daniel Fuchs wrote:
Hi,
Please find below a proposed patch for
8043306 - Provide a replacement for the API that allowed to listen
for LogManager configuration changes
https://bugs.openjdk.java.net/browse/JDK-8043306
On 9/10/14 2:25 PM, Paul Sandoz wrote:
FWIW i think you could do:
removeIf(e - listener == e);
Ah ah. Interesting!
Idiomatically callback methods are often prefixed with on:
onConfigurationLoaded.
Thanks! Exactly what I was looking for :-)
I'll wait for more comments before
On 9/10/14 4:28 PM, Jason Mehrens wrote:
Daniel
I think you should be able to remove the 'other instanceof
ConfigurationListener' branch in the ConfigurationListener.equals method.
Should work the same with or without that branch.
Oh yes. I put it there just to avoid it being flagged by
1 - 100 of 1534 matches
Mail list logo
