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 in
Changeset: 5bcaf730ceb8
Author:tyan
Date: 2013-11-29 09:29 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8
8029348: ProblemList.txt updates (11/2013)
Reviewed-by: chegar
! test/ProblemList.txt
To keep things clear and obvious in the bug report, I pushed this under a new
bug number, 8029348. You should update 6933803, including a summary of the
details in this thread.
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8
Thanks,
-Chris.
On 26 Nov 2013, at 15:47, Tristan Yan
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 of the deadlock.
Hi Daniel,
I explained why
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 of
Hi,
Here is a new revision that includes Peter's findings.
Thanks again for that Peter!
http://cr.openjdk.java.net/~dfuchs/webrev_8029281/webrev.01/
It has passed all jdk_core tests and running the new tests
in a loop hasn't triggered any of the issues that appeared
before the fix.
-- daniel
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 failure occurs on some windows test machines.
this replaces a Thread.sleep(5000)
Hi everyone, the summary of this issue is that it seems like
java.security.BasicPermission.implies() executes a useless check that
duplicates the functionality provided by java.lang.String.startsWith().
Below is a jdk7 code for java.security.BasicPermission.implies() method
with the lines of
On 29/11/2013 14:43, Alex Yursha wrote:
Hi everyone, the summary of this issue is that it seems like
java.security.BasicPermission.implies() executes a useless check that
duplicates the functionality provided by java.lang.String.startsWith().
Below is a jdk7 code for
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 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 have to be very careful as the logging
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
Hi Daniel,
Thanks for the feedback.
That's a fair point about the Thread construction.
In addressing the issue, I took a minimalist approach and
mainly homed in on the Thread.sleep prior to the server send,
as the potential culprit.
As the intermittent failure is on the client DatagramSocket
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 failure occurs on some windows test
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
On 19/11/2013 17:58, Ivan Gerasimov wrote:
Hello all!
Would you please help review a fix for the bug?
https://bugs.openjdk.java.net/browse/JDK-6968459
It was reported that creating new InitialLdapContext() can fail with
javax.naming.NamingException: LDAP response read timed out, timeout
Alan, Daniel,
thanks for the replies.
yes, 'tis a possibility, and it appears to work ok as a test, as it
avoids the sender's Thread.sleep creating a race condition, such that
the send doesn't happen prior to the timeout of the client receive.
The context of the test appears to be creating
Hi Charles,
My apology for the late response. I was on vacation the past week and
did not have full email
access.
As Sean pointed out, this is triggered by the change we just put in
recently for 8008386, in which
tried to address a strong request that asked for case like 'fe' '40' to
be
Thank you Alan for the reply!
On 29.11.2013 21:03, Alan Bateman wrote:
On 19/11/2013 17:58, Ivan Gerasimov wrote:
Hello all!
Would you please help review a fix for the bug?
https://bugs.openjdk.java.net/browse/JDK-6968459
It was reported that creating new InitialLdapContext() can fail with
19 matches
Mail list logo
