utor is an interface and a user could provide any implementation class,
so possible a user would throw any another RuntimeException or even an Error in
this case.
Shanliang
> On 12 Nov 2015, at 13:13, Jaroslav Bachorik
> wrote:
>
> Please, review the following test cha
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
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
mpMap.putIfAbsent(p.getObjectNamePattern(), 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
/PlatformMBeanProviderImpl: for the
MBeans in com.sun.management.* com.sun.management.* (jdk.management module)
Thanks,
Shanliang
unt() will not be changed any more.
This is why the test is timeout.
I reproduced the bug by inserting at line 99:
Thread.sleep(1000);
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
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 ar
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/20
e 202:
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
Jaroslav Bachorik wrote:
Hi,
On 12/12/2014 09:56 AM, shanliang wrote:
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 t
rowse/JDK-8066952
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8066952/00/
Thanks,
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.do
emove the waiting time specified 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
Jaroslav Bachorik wrote:
On 12/02/2014 06:56 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/02/2014 05:22 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/02/2014 04:22 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/02/2014 02:40 PM, shanliang wrote:
Jaroslav Bachorik wrote
Jaroslav Bachorik wrote:
On 12/02/2014 05:22 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/02/2014 04:22 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/02/2014 02:40 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/01/2014 02:50 PM, shanliang wrote:
Hi,
please review this
Jaroslav Bachorik wrote:
On 12/02/2014 04:22 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/02/2014 02:40 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/01/2014 02:50 PM, shanliang wrote:
Hi,
please review this test bug fix:
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8065764
Jaroslav Bachorik wrote:
On 12/02/2014 02:40 PM, shanliang wrote:
Jaroslav Bachorik wrote:
On 12/01/2014 02:50 PM, shanliang wrote:
Hi,
please review this test bug fix:
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/
bug:
https://bugs.openjdk.java.net/browse/JDK-8065764
test
Jaroslav Bachorik wrote:
On 12/01/2014 02:50 PM, shanliang wrote:
Hi,
please review this test bug fix:
webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8065764/00/
bug:
https://bugs.openjdk.java.net/browse/JDK-8065764
test/javax/management/monitor/CounterMonitorTest.java
L61 - observedValue
on calling:
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
Fabrice,
I remember that it was intended to create that thread as non-daemon, in
order to keep your JVM alive in case that there is no any other thread.
So you have to stop your JMXMP server before stopping the JVM
Shanliang
Fabrice Bacchella wrote:
I found a bug with the current
/Modules.gmk
Thanks,
Shanliang
Mandy Chung wrote:
On 10/15/2014 9:04 AM, Mandy Chung wrote:
Hi Shanliang,
On 10/15/2014 8:19 AM, shanliang wrote:
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/
Thanks for taking this on. The fix looks okay. I think you should
also
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/
I add:
./01/jdk9-make/
for updating ./make/CompileJavaModules.gmk
./01/jdk9-jdk-src/ is same to ./00
Thanks,
Shanliang
Erik Joelsson wrote:
Hello,
Removing the excludes would be appreciated. Here is a patch
Hi,
SNMP is not part of OpenJDK and SNMP packages are not compiled in
OpenJDK, so the SNMP sources should be deleted from the OpenJDK
Bug: https://bugs.openjdk.java.net/browse/JDK-8060692
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8060692/00/
Thanks,
Shanliang
s.
Thanks David 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 threa
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 chec
some 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
hope to have
useful info if the test failed on the second step.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8050115/02/
Thanks,
Shanliang
Daniel Fuchs wrote:
On 9/17/14 10:55 AM, shanliang wrote:
David Holmes wrote:
On 17/09/2014 7:01 AM, shanliang wrote:
David
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
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
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 this
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:
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
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
Jaroslav Bachorik wrote:
Hi,
On 09/11/2014 12:31 PM, Daniel Fuchs wrote:
On 9/10/14 9:45 PM, shanliang wrote:
Oh, not one retry attempt fetching the next batch of notifications, but
the *SAME* batch of notifications.
http://cr.openjdk.java.net/~sjiang/JDK-8049303/02/
<h
Daniel Fuchs wrote:
On 9/10/14 9:45 PM, shanliang wrote:
Oh, not one retry attempt fetching the next batch of notifications, but
the *SAME* batch of notifications.
http://cr.openjdk.java.net/~sjiang/JDK-8049303/02/
<http://cr.openjdk.java.net/%7Esjiang/JDK-8049303/02/>
Shanliang
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.
Y
mpt
// at fetching the next batch of notifications - and the
// problem 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.o
r.openjdk.java.net/~sjiang/JDK-8049303/00/
<http://cr.openjdk.java.net/%7Esjiang/JDK-8049303/00/>
Thanks,
Shanliang
{
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 08/21/2014 03:55 PM, shanliang wrote:
Jaroslav,
The fix should be good to fix the failure.
It makes me think a special case, suppose that the test waits 2
notifications, but the test might receive one unexpected notification
with some more waiting, for example
first second, and the unexpected arrives
in the second second, but with your fix the test might end before the
unexpected notification arrives.
Not sure that we should take care of this case.
Thanks,
Shanliang
Jaroslav Bachorik wrote:
Please, review the following test change.
Issue : https
Jaroslav Bachorik wrote:
On 07/01/2014 09:20 PM, shanliang wrote:
So the issue (race cases) is from the implementation and detected by the
test, it meant that the thread info could be incorrect in some cases,
and your fix is to ask the test to try again in this case.
Yes. That should give the
in the ThreadMXBean Javadoc? or for some reason this
could be ignored?
I am looking at JDK-8048215
<https://bugs.openjdk.java.net/browse/JDK-8048215> and thinking that it
might be same issue.
Shanliang
Jaroslav Bachorik wrote:
Please, review this test fix.
Issue :
Hi,
Please review the following fix:
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8044865/00/
<http://cr.openjdk.java.net/%7Esjiang/JDK-8044865/00/>
bug: https://bugs.openjdk.java.net/browse/JDK-8044865
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
arness timeout.
Thanks,
Shanliang
wse/JDK-8038940
Thanks,
Shanliang
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
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 was not
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
r could be created at the beginning of
the test. That would resolve all the port number passing.
and no need to create a thread to listen on the server socket, like
JMXStartStopDoSomething.serverThread.
Shanliang
-JB-
-- daniel
On 2/14/14 3:43 PM, Daniel Fuchs wrote:
Hi Jaroslav,
I agre
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
This is a simple test fix, have to remove the test in OpenJDK because
the SNMP classes in the OpenJDK will not be compiled if the closed part
is not present.
diff8029063-open
Description: video/flv
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
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
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
Looks fine to me.
Shanliang
Jaroslav Bachorik wrote:
On 2.10.2013 12:55, Jaroslav Bachorik wrote:
On 20.9.2013 14:54, shanliang wrote:
Jaroslav,
It is a good idea to use the RMI Testlibrary.
Better to call:
agent.close();
at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort
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
Daniel Fuchs wrote:
Hi Shanliang,
Shouldn't 'messageReceived' be at least declared as volatile?
It looks as if this test is a multi-thread test which
is not MT-safe.
OK I am convinced:
http://cr.openjdk.java.net/~sjiang/JDK-8025206/02/
Thanks,
Shanliang
cheers,
-- danie
Daniel Fuchs wrote:
Hi Shanliang,
Shouldn't 'messageReceived' be at least declared as volatile?
It looks as if this test is a multi-thread test which
is not MT-safe.
Could be better, but the test is patient enough with its timeout :)
Shanliang
cheers,
-- daniel
On
Thanks Jaroslav for the review, here is the new version with the
debugging info:
http://cr.openjdk.java.net/~sjiang/JDK-8025206/01/
Shanliang
Jaroslav Bachorik wrote:
Hi Shanliang,
On 30.9.2013 08:55, shanliang wrote:
Hi,
Please review this test fix, I set a much long waiting time to
,
Shanliang
Hi,
Simply wait longer time for a broken notif.
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8025205
Thanks,
Shanliang
Daniel Fuchs wrote:
On 9/23/13 8:27 PM, shanliang wrote:
Hi,
Please review this test fix, if the test continues failing, then we need
to investigate the Monitor implementation.
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8025207
Hi,
Please review this test fix, if the test continues failing, then we need
to investigate the Monitor implementation.
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8025207
Thanks,
Shanliang
https://bugs.openjdk.java.net/browse/JDK-8025204
Thanks,
shanliang
Jaroslav,
It is a good idea to use the RMI Testlibrary.
Better to call:
agent.close();
at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort) Line 55)
does not ensure the JMX connector doing full clean, it is always better
to do clean within a test.
Shanliang
Jaroslav
Hi,
Still need OK from a code reviewer, thanks Daniel for the review.
Web: http://cr.openjdk.java.net/~sjiang/jdk-8023954/01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8023954
Thanks,
Shanliang
P.S.
The bug id is 8023954, not 8023529, I put the wrong bug ID in the
previous mails
The fix looks OK for me.
I am wondering that in case of loopback address, is it better to always
using "127.0.0.1" to generate a connectionId? this will make sure to
have a unique id.
Shanliang
Jaroslav Bachorik wrote:
Please, review this simple patch for an intermittently fa
missed.
I get used to add more info, because sometime we miss info when a test
fails.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/jdk-8023529/02/
Thanks,
Shanliang
David
-
Thanks,
Shanliang
David
-
On 11/09/2013 12:15 AM, shanliang wrote:
Jaroslav Bachorik wrote:
Daniel Fuchs wrote:
On 9/11/13 2:05 AM, David Holmes wrote:
On 30/08/2013 12:11 AM, shanliang wrote:
Here is the new version:
http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
This seems good to address the NPE potential.
You are changing the values of the hashcodes though - is that a
some problems to generate
the version 01, so the version 00 was re-generated by mistake with
another fix, sorry for this confusing.
Thanks,
Shanliang
David
-
On 11/09/2013 12:15 AM, shanliang wrote:
Jaroslav Bachorik wrote:
On 09/05/2013 10:37 AM, shanliang wrote:
I have added 2 tas
David Holmes wrote:
On 30/08/2013 12:11 AM, shanliang wrote:
Here is the new version:
http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
This seems good to address the NPE potential.
You are changing the values of the hashcodes though - is that a problem?
Good question!
It should not be
Jaroslav Bachorik wrote:
On 09/05/2013 10:37 AM, shanliang wrote:
I have added 2 tasts to make sure that call
OpenMBean*InfoSupport.equals/hashCode do not throw NPE
The unit tests and JCK tests are passed.
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
Bug: https
Daniel Fuchs wrote:
On 9/6/13 1:24 PM, shanliang wrote:
Hi,
Thanks to review the following fix:
webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8023954
Shanliang
Hi Shanliang,
Looks good - but it looks as if some hashCode() will
Hi,
Thanks to review the following fix:
webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8023954
Shanliang
I have added 2 tasts to make sure that call
OpenMBean*InfoSupport.equals/hashCode do not throw NPE
The unit tests and JCK tests are passed.
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8023529
Thanks,
Shanliang
Looks good, simple but workable solution!
Shanliang
Jaroslav Bachorik wrote:
Please, review the following patch:
http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
It addresses the problem of the test not properly cleaning up the
management are passed too in my desk.
toString() worked perfectly in the test, nothing to fix.
Shanliang
Daniel Fuchs wrote:
On 8/29/13 9:34 AM, shanliang wrote:
Hi,
Please review following fix, it addresses the issue only in the method
"hashCode":
bug: https://bugs.openjdk.java.
Thanks David.
Shanliang
David Holmes wrote:
Hi Shanliang,
After our off-list discussion I've had a closer look at this and it
looks okay to me too.
Reviewed.
Thanks,
David
On 26/08/2013 6:35 PM, shanliang wrote:
Hi,
Still need OK from a reviewer.
Thanks Erik, Jaroslav and Danie
Hi,
Please review following fix, it addresses the issue only in the method
"hashCode":
bug: https://bugs.openjdk.java.net/browse/JDK-8023669
webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
Thanks,
Shanliang
Hi,
Still need OK from a reviewer.
Thanks Erik, Jaroslav and Daniel for the code review.
Thanks,
Shanliang
Daniel Fuchs wrote:
On 8/21/13 10:27 AM, shanliang wrote:
Jaroslav Bachorik wrote:
On 08/21/2013 12:00 AM, Daniel Fuchs wrote:
On 8/20/13 11:12 PM, shanliang wrote:
Thanks Daniel
webrev: http://cr.openjdk.java.net/~sjiang/JDK-6566891/00/
shanliang wrote:
Hi,
Please review:
webrev:
http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/
bug: https://jbs.oracle.com/bugs/browse/JDK-6566891
I have passed JCK tests and unit tests.
Thanks,
Shanliang
Hi,
Please review:
webrev: http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/
bug: https://jbs.oracle.com/bugs/browse/JDK-6566891
I have passed JCK tests and unit tests.
Thanks,
Shanliang
Jaroslav Bachorik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/24/2013 10:38 AM, shanliang wrote:
- ---> MBean.getThreadCount() = 7
- ---> MBean.getThreadCount() = 6
I suppose that you added sleep between 2 calls, then there might be
an issu
- ---> MBean.getThreadCount() = 7
- ---> MBean.getThreadCount() = 6
I suppose that you added sleep between 2 calls, then there might be an
issue with MBean.getThreadCount()
Shanliang
Jaroslav Bachorik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/24/2
Just to be a test, after terminated 8 threads and checked their states
by calling Thread.join() (must be same to Thread.getState()), DO sleep
sometime and then call mbean.getThreadCount(), if it reports a right
number, then we may need to verify mbean.getThreadCount() method.
Shanliang
)
this is because it is possible that a MyThread is suspended after calling:
barrier.signal();
but before leaving run() method, especially when stopping many threads
at same time on a slow testing machine.
Shanliang
Jaroslav Bachorik wrote:
The java/lang/management/ThreadMXBean
ith
other situations, like the connection was cut in the middle way of
fetching, then the fix would make ClientNotifForwarder fail to stop
fetching.
Shanliang
Jaroslav Bachorik wrote:
Please, review the change.
http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/
The combination of the f
It looks fine to me.
Shanliang
Jaroslav Bachorik wrote:
Please, review this simple fix.
http://cr.openjdk.java.net/~jbachorik/8019826/webrev.00
Firstly, the patch removes a conditional early exit which checks for a
build 52 of an unspecified major JVM version - it is not needed any
more
Jaroslav Bachorik wrote:
On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
Jaroslav,
It is now OK for me about the MBean interface searching in the
Introspector.
Here is my comment on JMX.java:
206 -- 212 you added a call
Introspector.testComplianceMBeanInterface(interfaceClass
because the real job is done in newProxyInstance and it could be
directly called by anyone.
All others are OK for me.
Shanliang
Jaroslav Bachorik wrote:
On Wed 05 Jun 2013 07:54:10 PM CEST, shanliang wrote:
Daniel Fuchs wrote:
On 6/5/13 3:55 PM, Jaroslav Bachorik wrote:
class
s an instance of AMBean, according to 2), A is a standard MBean
and AMBean must be taken,
3) specifies the condition as "If the MBean is an instance of neither
MyClassMBean nor DynamicMBean", our example is out of this condition, so
should not apply 3) to our example.
Shanliang
Jaroslav Bachorik wrote:
On Wed 05 Jun 2013 11:34:05 AM CEST, shanliang wrote:
Jaroslav Bachorik wrote:
On 05/30/2013 09:32 AM, Jaroslav Bachorik wrote:
On Wed 29 May 2013 07:44:34 PM CEST, Daniel Fuchs wrote:
On 5/29/13 7:17 PM, Jaroslav Bachorik wrote
terface.getName())) {
370 return mbeanInterface;
371 }
As I indicated in my previous mail, better to write as:
if (clMBeanName.equals(mbeanInterface.getName() &&
(Modifier.isPublic(mbeanInterface.getModifiers()) ||
MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)
ason to not have a unit test?
Shanliang
Jaroslav Bachorik wrote:
And the webrev would come handy, of course.
http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
-JB-
On 05/28/2013 04:22 PM, Jaroslav Bachorik wrote:
The fix enforces the management interfaces (read MBean and MXBean
Jaroslav,
The fix is OK for me.
The class MBeanInfo could be simplified because the constructors ensure
that attributes, constructors, operations and notifications are not
null, then we can remove all those nonNullxxx methods.
Shanliang
Jaroslav Bachorik wrote:
Please, review the fix for
1 - 100 of 121 matches
Mail list logo
