We could repeat retrying until the test harness timeout, but add a sleep is
definitively useful between retrying.
Shanliang
> On 23 Nov 2015, at 12:32, Daniel Fuchs <daniel.fu...@oracle.com> wrote:
>
> Hi Alexander,
>
> This looks a bit dangerous to me - it cou
> On 13 Nov 2015, at 09:04, Jaroslav Bachorik <jaroslav.bacho...@oracle.com>
> wrote:
>
> On 13.11.2015 08:05, Shanliang JIANG wrote:
>> Hi Jaroslav,
>>
>> The issue is that after a JMX client is terminated, its
>> ClientNotifForwarder continues deliv
) {
executor.execute(new NotifFetcher());
}
}
Thanks to work on this issue.
Shanliang
> On 10 Nov 2015, at 12:36, Alexander Kulyakhtin
> <alexander.kulyakh...@oracle.com> wrote:
>
> Hi Jaroslav, Shanliang Jiang
>
> Thank you very much for the review.
>
Iris,
The fix ooks good.
Shanliang
Iris Clark wrote:
Hi.
Please review changes to resolve the following bug:
8132003: Update javax/management regression test for Verona (versioning)
Bug: https://bugs.openjdk.java.net/browse/JDK-8132003
The regression test javax/management/remote/mandatory
Looks good to me!
Shanliang
Jaroslav Bachorik wrote:
Please, review the following simple change
Issue : https://bugs.openjdk.java.net/browse/JDK-8029098
Webrev: http://cr.openjdk.java.net/~jbachorik/8029098/webrev.00
The 'ListenerScaleTest' is meant to check the proper scaling of the
MBean
any help to create the bug.
Shanliang
KUBOTA Yuji wrote:
My apologies for re-post, I forgot to register serviceability-dev
before the last post.
Hi Shanliang,
Thanks you for your help!
RMI_CLIENT_SOCKET_FACTORY_ATTRIBUTE is a nice workaround.
However, many users believe
KUBOTA Yuji wrote:
Hi Shanliang,
Many thanks for your help!
I do not have any role yet. So I can not create a new bug at JBS. It's
a reason why I submitted a mail with my patch at first.
This issue is caused by a rare network problem during the flush() [3]
. I got this infinite loop only
,
this allows you to specify your SoTimeout.
Hope this helps.
Shanliang
KUBOTA Yuji wrote:
Hi all,
I want to contribute this issue.
If there are a problem about this patch or a better way for openjdk
community, please advise me.
Thanks for
2015-04-22 0:31 GMT+09:00 KUBOTA Yuji kubota.y
but in jdk.management module, to get the HotSpotDiagnosticMXBean
we should call:
ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
I passed all failed tests with the fix.
Thanks,
Shanliang
Alan Bateman wrote:
On 21/04/2015 08:01, Shanliang Jiang wrote:
Hi,
Please review this test fix:
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8078144
The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean
was removed
-8077408/00/
Thanks,
Shanliang
standard MXBean class (java.lang.management.*), do check still needs
jdk.management module to be present.
We need more unit tests for the case when jdk.management is absent.
Thanks,
Shanliang
integrated also the Mandy's comments in the following mail.
Thanks,
Shanliang
Mandy Chung wrote:
On 3/31/2015 9:39 AM, shanliang wrote:
Please review this fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
Thank you for doing this big
Jaroslav Bachorik wrote:
Hi Shanliang,
Looks good! A lot of work here ...
Just a nit -
*
jdk/src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java
- superfluous import @L28 (and the copyright year change)
Yes the import of L28 is unnecessary
that flag stting in libmanagement,
and I copied it for libmanagement_ext.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8042901/01/
Thanks for the review.
Shanliang
/Erik
On 2015-03-31 18:39, shanliang wrote:
Please review this fix:
Bug: https://bugs.openjdk.java.net
of the server
termination, so the client can safely stop fetching.
The fix was tested in the environment where the bug was reported.
Thanks,
Shanliang
FILES, read),
890 new
RuntimePermission(sun.management.spi.PlatformMBeanProvider));
2)
The modification to Flag is removed, we get another solution to know
whether commercial feature is enabled.
3) some mis minors modifications.
Thanks,
Shanliang
(), p));
}
You must know that code was changed :)
PlatformMBeanProviderImpl.java:
105 * 3 OperatingSystemMXBean
Not sure what '3' means here - I suggest to remove it.
OK
Thanks,
Shanliang
waitForThreadState tests it, so it is supposed to be possible to get it,
when it is true then the testing method might return with a thread state
different to the waited one.
Shanliang
Jaroslav Bachorik wrote:
On 29.1.2015 14:43, shanliang wrote:
Jaroslav Bachorik wrote:
Please, review the following test change.
Issue : https://bugs.openjdk.java.net/browse/JDK-8071641
Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/
The test fails very intermittently
/PlatformMBeanProviderImpl: for the
MBeans in com.sun.management.* com.sun.management.* (jdk.management module)
Thanks,
Shanliang
Hi,
Please review this simple fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8068591
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/
Thanks,
Shanliang
Jaroslav Bachorik wrote:
On 8.1.2015 15:35, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 8.1.2015 14:59, shanliang wrote:
Hi,
Please review this simple fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8068591
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00
David,
Here is the new version, I have added the comments as you suggested, and
I replaced the variable sources with a synchronized list.
http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/
Thanks for the review.
Shanliang
David Holmes wrote:
Hi Shanliang,
On 6/01/2015 3:47 AM, shanliang
David Holmes wrote:
On 6/01/2015 9:03 PM, shanliang wrote:
David,
Here is the new version, I have added the comments as you suggested, and
I replaced the variable sources with a synchronized list.
Why did you do that ?? Vector is synchronized so it was fine for the job.
You are right! I
:
try {
Thread.sleep(5100);
} catch (Exception ee) {}
to delay the t's dying.
The fix is to replace:
t.join(5000L);
by:
t.join();
and replace:
Object.wait(timeout);
by
CountDownLatch.countDown();
The test harness timeout will be used as the max waiting timeout.
Shanliang
Daniel Fuchs wrote:
Hi Shanliang,
These two statements are no longer needed and should be removed - as they
are misleading:
64 if (!bb.gotLock) {
65 throw new RuntimeException(Failed to get lock, impossible!);
66 }
81 if (!wb.done) {
82
://cr.openjdk.java.net/~sjiang/JDK-8066952/00/
Thanks,
Shanliang
in the test, the timeout
of test harness will be used as the max waiting time.
bug: https://bugs.openjdk.java.net/browse/JDK-8067241
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/
thanks,
Shanliang
:
StdObservedObject.getNbObjects();
Thanks,
Shanliang
Hi, Here is version 2:
http://cr.openjdk.java.net/~sjiang/JDK-8046192/01/
The modification in ./jdk/src was missed in the first version.
The webreviews show only modification in the public part.
Thanks,
Shanliang
shanliang wrote:
Hi,
The fix is to remove unnecessary exports for jdk.snmp
Hi,
The fix is to remove unnecessary exports for jdk.snmp module.
bug: https://bugs.openjdk.java.net/browse/JDK-8046192
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8046192/00/
Thanks,
Shanliang
for the review.
Shanliang
Thanks,
David
On 18/09/2014 1:09 AM, shanliang wrote:
Daniel Fuchs wrote:
On 9/17/14 4:43 PM, shanliang wrote:
Daniel,
We could not be sure that the test failed of timeout, that's why I
tried
to add more checks.
The check for Step 1: all thread traces were printed out only
David Holmes wrote:
On 17/09/2014 7:01 AM, shanliang wrote:
David Holmes wrote:
Hi Shanliang,
On 16/09/2014 7:12 PM, shanliang wrote:
Hi,
Please review the following fix:
I don't see any functional change. You seem to have replaced a
built-in timeout with the externally applied test
useful info from these 2 checks.
It must not be so heavy but still could impact the test, your suggestion
to use test.timeout.factor is a good idea, I added the code to calculate
the checking time based on it:
http://cr.openjdk.java.net/~sjiang/JDK-8050115/03/
Thanks,
Shanliang
Daniel Fuchs
Daniel Fuchs wrote:
On 9/17/14 4:43 PM, shanliang wrote:
Daniel,
We could not be sure that the test failed of timeout, that's why I tried
to add more checks.
The check for Step 1: all thread traces were printed out only if
deadlock was found, and the test failed immediately.
The check
Hi,
Please review the following fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8050115
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8050115/00/
Thanks,
Shanliang
Daniel Fuchs wrote:
Hi Shanliang,
line 116 - you could use a CountDownLatch instead of an
AtomicInteger. It would avoid having to use the busy loop at
lines 134-136.
Yes CountDownLatch is really a good idea, I tried to modify the code as
less as possible, I prefer to keep the old code
David Holmes wrote:
Hi Shanliang,
On 16/09/2014 7:12 PM, shanliang wrote:
Hi,
Please review the following fix:
I don't see any functional change. You seem to have replaced a
built-in timeout with the externally applied test harness timeout.
Yes no functional change here, we thought
Hi,
Please review the following fix, I changed the way to check received
notifications.
Bug: https://bugs.openjdk.java.net/browse/JDK-8042205
Webrec: http://cr.openjdk.java.net/~sjiang/JDK-8042205/00/
http://cr.openjdk.java.net/%7Esjiang/JDK-8042205/00/
Thanks, shanliang
Daniel Fuchs wrote:
Looks good Shanliang.
The synchronization is a bit strange, with the flag being
volatile and sometime modified within synchronized blocks and
sometime being modified outside of any s-block, but I believe
it is working (AFAIU the synchronized is mostly needed because
you call
/management/monitor/ReflectionExceptionTest.java
+javax/management/monitor/RuntimeExceptionTest.java
+javax/management/monitor/AttributeArbitraryDataTypeTest.java
+
Thanks,
Shanliang
persisted.
// Since trying again doesn't seem to solve the issue, we will now
// close the connection. Doing otherwise might cause the
// NotifFetcher thread to die silently.
Yes more clear, here is the new webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8049303/01/
Thanks Daniel!
Shanliang
best
shanliang wrote:
Daniel Fuchs wrote:
Hi,
Thanks for the detailed explanations.
The fact that the server doesn't store any client state
and can arbitrarily close the connection, leaving it to
the client to reestablish the connection, makes all this
code quite tricky and hard to follow.
Yes
{
popDefaultClassLoader(old);
}
with the suggested fix, no more second call of connection.createMBean
(Yes, we need more tests to cover these cases).
So a fix is better added in RMIConnector.RMINotifClient.fetchNotifs.
Thanks,
Shanliang
Jaroslav Bachorik wrote:
On 08/29/2014 11
Jaroslav Bachorik wrote:
On 07/01/2014 11:40 PM, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 07/01/2014 09:47 PM, shanliang wrote:
I am still thinking to keep the original fix, because:
1) to throw InterruptedException does not fix the test failure, it
might
give more info
thread, in which case and why, and whether
possible to ignore it (skip the test or try again?).
2) the test library is used also by other tests and to modify it might
make new fail, it is better to concentrate at first on a single test
before knowing the exact cause.
Shanliang
Christian Tornqvist
Jaroslav Bachorik wrote:
Hi Shanliang,
On 07/01/2014 09:47 PM, shanliang wrote:
I am still thinking to keep the original fix, because:
1) to throw InterruptedException does not fix the test failure, it might
give more info for diagnostics. If it was really caused by an
InterruptedException
/
Thanks,
Shanliang
Jaroslav Bachorik wrote:
Hi Shanliang,
On 06/26/2014 03:15 PM, shanliang wrote:
Hi,
Today ProcessTools.executeProcess has the code:
new OutputAnalyzer(pb.start());
and OutputAnalyzer constructor calls immediately:
exitValue = process.exitValue();
the test got exception because
.
bug: https://bugs.openjdk.java.net/browse/JDK-8038321
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038321/00/
http://cr.openjdk.java.net/%7Esjiang/JDK-8038321/00/
Thanks,
Shanliang
timeout.
Thanks,
Shanliang
Daniel Fuchs wrote:
Hi Shanliang,
This looks reasonable to me.
Another possibility could have been to use the timeout factor
to adapt the delay of Thread.sleep in the loop.
Yes we could adapt our timeout, but it is simpler to use the testing
harness timeout.
What you have might be more
Staffan Larsen wrote:
On 8 apr 2014, at 22:10, shanliang shanliang.ji...@oracle.com wrote:
Hi Staffan,
I did work on this bug and I thought the problem was from a bad DISPLAY setting
(see my comments in the bug), I might miss something here.
I looked at the class GraphicsEnvironment.java
Staffan Larsen wrote:
On 9 apr 2014, at 10:24, shanliang shanliang.ji...@oracle.com
mailto:shanliang.ji...@oracle.com wrote:
Staffan Larsen wrote:
On 8 apr 2014, at 22:10, shanliang shanliang.ji...@oracle.com wrote:
Hi Staffan,
I did work on this bug and I thought the problem
, but I am not sure that the direct
call would fix the failure.
Thanks,
Shanliang
Staffan Larsen wrote:
This test causes exceptions that looks like this:
java.awt.AWTError: Can't connect to X11 window server using ‘REDACTED:503' as
the value of the DISPLAY variable
,
Shanliang
Jaroslav Bachorik wrote:
Hi,
Sorry for the noise but I need to get the fix re-reviewed.
Due to the way jtreg cooperates with TestNG when runnning in agentvm I
can not use package private methods or constructor or fields.
The updated patch -
http://cr.openjdk.java.net/~jbachorik
shanliang wrote:
Jaroslav,
Is it necessary to add ValidationException?
Could we change the constructor JInfo to:
private static boolean validateArgs(String[] args);
the method returns false if the args are illegal, or throw an
IllegalArgumentException
and declare the variables args
Jaroslav Bachorik wrote:
On 7.4.2014 14:10, shanliang wrote:
Jaroslav,
Is it necessary to add ValidationException?
Well, for the implementation when the validation is performed at the
moment a new instance of JInfo is being created it is necessary.
Could not use an existing Exception? like
,
Shanliang
of
SimulResumerTarg(name='Thread 2', id=109)
Shanliang
I looked at this failure before and I couldn't see what was wrong, not
in the test or product.
Erik
Jaroslav Bachorik skrev 3/27/14 4:49 PM:
On 27.3.2014 15:49, shanliang wrote:
Hi,
The call
thr.frames(0, frames.size() - 1);
suffers
Jaroslav Bachorik wrote:
Thanks Shanliang, it is clear now.
The patch will get rid off the IOOBE but I have my doubts about what
the test actually tests. It is supposed to make sure that certain
operations will not throw NPE when the debugged thread is resumed
(from a concurrent debugger
Hi,
The call
thr.frames(0, frames.size() - 1);
suffers a synchronization issue, the size may be changed after
frames.size() returns.
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-6815126/00/
bug:
https://bugs.openjdk.java.net/browse/JDK-6815126
Shanliang
Looks good!
It could be improved to not use the variable thresholdExceeded:
change Line 146 to
while(true) {
and remove Line 143 and 158
Thanks,
Shanliang
Mattias Tobiasson wrote:
Hi,
I have updated the test and now stop allocating when we have reached the
threshold.
Since we now do all
.
Shanliang
best regards,
-- daniel
bug:
https://bugs.openjdk.java.net/browse/JDK-8031065
webrev:
http://cr.openjdk.java.net/~ykantser/8031065/webrev.00/
Mattias
for(;;)
to
while(!listenerInvoked) {
and remove 160 -- 162
in case that an expected notification is not arrived, the testing
harness has a timeout to stop the test.
This way makes the test more robust, but I am OK with the current fix.
Thanks,
Shanliang
About line 172, you are correct. I will just
Jaroslav Bachorik wrote:
Hi Shanliang,
On 20.2.2014 19:20, shanliang wrote:
Jaroslav,
The failed tests were:
1, 7, 8, 9
but the tests using this port (port2: 50235) were
1, 3, 4, 6, 7, 8, 9
and tests 2,4,6 were passed.
so I think that the problem might be that the port
Jaroslav Bachorik wrote:
On 21.2.2014 10:26, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 20.2.2014 19:20, shanliang wrote:
Jaroslav,
The failed tests were:
1, 7, 8, 9
but the tests using this port (port2: 50235) were
1, 3, 4, 6, 7, 8, 9
and tests 2,4,6 were passed
by
the previous test.
Your solution is to create a Server socket on a free port, then release
it when a test needs it. I suspect whether we will fall into same issue
here: the port would not be fully released when using it?
Shanliang
Jaroslav Bachorik wrote:
Please, review this test fix.
Issue
.
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8035195/00
http://cr.openjdk.java.net/%7Esjiang/JDK-8035195/00/
bug:
https://bugs.openjdk.java.net/browse/JDK-8035195
Thanks,
Shanliang
this:
long stopTime = System.currentTimeMillis() + 5000;
do {
try {
bkptSignal.wait(100);
} catch (InterruptedException e){}
} while(prevBkptCount == bkptCount System.currentTimeMillis()
stopTime);
Shanliang
David Holmes wrote:
On 18/02
Staffan Larsen wrote:
This version looks good! Thanks for hanging in there.
The only improvement would be to count and verify the number of
ModificationWatchpointEvent (there should be 10).
Good idea, here is:
http://cr.openjdk.java.net/~sjiang/JDK-8007710/05/
Thanks,
Shanliang
Thanks
with a possibly unstable VM. in this case we
might have a serious bug in VirtualMachine implementation, and if this
is true the fix proposed to check start may make miss
ClassPrepareEvent, then the test would test nothing.
Shanliang
/S
-JB-
/Staffan
On 12 feb 2014, at 18:04, shanliang
is the new webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8007710/03/
Thanks,
Shanliang
Staffan Larsen wrote:
I think I understand what happens now.
The test code, simplified, looks like this (with the Thread.sleep()
added that causes the test to fail):
launchTarget();
addClassWatch
Hi,
Here is Version 4:
http://cr.openjdk.java.net/~sjiang/JDK-8007710/04/
1) remove the line
108 vm.resume()
2) call addClassWatch(vm) only when receiving VMStartEvent
3) make sure that the test receives ModificationWatchpointEvent
4) clean
Thanks,
Shanliang
shanliang wrote:
Staffan
StringBuffer near the top
of main().
Yes it was already removed in version 01
Here is the new webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/
Thanks,
Shanliang
Thanks,
/Staffan
On 11 feb 2014, at 18:30, shanliang shanliang.ji...@oracle.com wrote:
Here is the new fix
();
44 } catch (Exception e) {
45 System.out.println(---TestPostFieldModification-run impossible?
+e);
46 e.printStackTrace();
47 }
Done.
Thanks for reviewing.
Shanliang
Thanks,
Serguei
On 2/11/14 9:30 AM, shanliang wrote:
Here is the new fix
is that
FieldMonitor creates a file after adding field watching, and
TestPostFieldModification quits only after finding the file.
web:
http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/
bug:
https://bugs.openjdk.java.net/browse/JDK-8007710
Thanks,
Shanliang
public web:
http://cr.openjdk.java.net/~sjiang/JDK-8007710/00/
Shanliang
shanliang wrote:
Hi ,
The problem could be that FieldMonitor did not have enough time to
addFieldWatch but the vm to monitor (TestPostFieldModification) was
already ended.
So we should make sure
Jaroslav Bachorik wrote:
On 11.2.2014 16:31, shanliang wrote:
Staffan Larsen wrote:
Hi Shanliang,
I can’t quite see how the test can fail in this way. When the
ClassPrepareEvent happens, the debuggee will be suspended. So when
addFieldWatch() is called, the debuggee should not have moved.
I
Here is the new fix in which FieldMonitor will write to
TestPostFieldModification, to inform the latter to quit, as suggested bu
Jaroslav
http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/
Thanks,
Shanliang
shanliang wrote:
shanliang wrote:
Jaroslav Bachorik wrote:
On 11.2.2014 16:31
Jaroslav,
Your fix should work in most case, but is it better and more reliable to
wait a VM event as suggested in the bug? even your timeout is adapted to
the test time factory, but the solution still depends to a fixed timeout
and a fixed line out.
Shanliang
Jaroslav Bachorik wrote
Jaroslav Bachorik wrote:
On 4.2.2014 09:54, shanliang wrote:
Jaroslav,
Your fix should work in most case, but is it better and more reliable to
wait a VM event as suggested in the bug? even your timeout is adapted to
the test time factory, but the solution still depends to a fixed timeout
Jaroslav Bachorik wrote:
Looks good.
Just a side question - why are you using the divider of 10 (and the
original divider is 20)?
Did change to 20 in the last version :)
I tested with different dividers and got almost same running time with
10 and 20.
Thanks,
Shanliang
-JB
faster with:
chunkSize = Runtime.getRuntime().freeMemory()/10;
than:
chunkSize = 1M;
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-6980984/00/
bug:
https://bugs.openjdk.java.net/browse/JDK-6980984
Thanks,
Shanliang
Jaroslav Bachorik wrote:
Hi Shanliang,
On 22.1.2014 14:27, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime().maxMemory()
Runtime.getRuntime().totalMemory
Jaroslav Bachorik wrote:
On 22.1.2014 15:32, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 22.1.2014 14:27, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on
7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime
, but that seems not important for
the test.
Thanks,
Shanliang
Daniel Fuchs wrote:
Hi Shanliang,
I just notice that there are some synchronization
issues in the test as well: all static variables
used by the allocator thread should be declared
volatile (chunkSize, mpool ...).
-- daniel
On 1/22/14 2
Olivier,
Now it is 2014 :)
Olivier Lagneau wrote:
Please review the following simple fix.
Issue: https://bugs.openjdk.java.net/browse/JDK-8019389
Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.00/
http://cr.openjdk.java.net/%7Eolagneau/8019389/webrev.00/
The issue is due to
David Holmes wrote:
On 16/01/2014 5:37 PM, shanliang wrote:
Hi,
Please review this simple fix, the test needs more time to wait
Phaser.awaitAdvanceInterruptibly(...).
Integer.MAX_VALUE? There's no point using a timed form at all.
David
Yes Phaser.awaitAdvanceInterruptibly(int phase) could
Jaroslav Bachorik wrote:
On 16.1.2014 11:48, shanliang wrote:
David Holmes wrote:
On 16/01/2014 5:37 PM, shanliang wrote:
Hi,
Please review this simple fix, the test needs more time to wait
Phaser.awaitAdvanceInterruptibly(...).
Integer.MAX_VALUE? There's no point using a timed form
David Holmes wrote:
On 16/01/2014 9:01 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 16.1.2014 11:48, shanliang wrote:
David Holmes wrote:
On 16/01/2014 5:37 PM, shanliang wrote:
Hi,
Please review this simple fix, the test needs more time to wait
Phaser.awaitAdvanceInterruptibly
Hi,
Please review this simple fix, the test needs more time to wait
Phaser.awaitAdvanceInterruptibly(...).
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8029378/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8029378
Thanks,
Shanliang
The fix looks OK.
Line 232 is not necessary.
The simplest fix might be only to add the following lines to 94
if (getPlatform() == null) {
return;
}
Shanliang
Jaroslav Bachorik wrote:
Please, review this small test change.
Issue : https://bugs.openjdk.java.net/browse/JDK-8031420
Webrev
Changeset: c11553506228
Author:sjiang
Date: 2013-12-03 08:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c11553506228
8029063: test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with
OpenJDK builds
Reviewed-by: alanb, dfuchs
-
Jaroslav,
Look fine to me, thanks to fix the timing.
Next time we may need to fix its fixed port:)
Shanliang
Jaroslav Bachorik wrote:
Hi,
please, review the following small test change:
Issue: https://bugs.openjdk.java.net/browse/JDK-7140929
Webrev: http://cr.openjdk.java.net/~jbachorik
Looks OK.
164 // sanity check to have non-zero usage
should be changed to ?
164 // sanity check to have non-negative usage
Shanliang
Jaroslav Bachorik wrote:
Please, review this simple test fix.
Issue: https://bugs.openjdk.java.net/browse/JDK-7112404
Webrev: http
Changeset: 4161f17dfe2b
Author:sjiang
Date: 2013-10-18 16:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4161f17dfe2b
8026028: [findbugs] findbugs report some issue in com.sun.jmx.snmp package
Reviewed-by: psandoz, dfuchs
!
Thanks Paul and Daniel for the review.
Shanliang
Daniel Fuchs wrote:
Hi Shanliang,
Looks good!
-- daniel
On 10/16/13 3:58 PM, shanliang wrote:
Hi,
Please review the following fix, main issue here is that we should clone
an internal variable before returning.
webrev:
http
Hi,
Please review the following fix, main issue here is that we should clone
an internal variable before returning.
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8026028/00/
bug
https://bugs.openjdk.java.net/browse/JDK-8026028
Thanks,
Shanliang
1 - 100 of 184 matches
Mail list logo
