Hi David,
I uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8186018/webrev.01/
2017-08-09 15:32 GMT+09:00 David Holmes :
> Hi Yasumasa,
>
> On 9/08/2017 3:54 PM, Yasumasa Suenaga wrote:
>>
>> Hi all,
>>
>> I tried to check Monitor Cache Dump in HSDB, but it hangs and OOME
>> occu
Hi Yasumasa,
On 9/08/2017 3:54 PM, Yasumasa Suenaga wrote:
Hi all,
I tried to check Monitor Cache Dump in HSDB, but it hangs and OOME occurred.
How to reproduce:
1. Run JShell
2. Attach HSDB to JShell
$ jhsdb hsdb --pid
3. Select "Monitor Cache Dump" in "Tools" menu.
ObjectSy
Hi all,
I tried to check Monitor Cache Dump in HSDB, but it hangs and OOME occurred.
How to reproduce:
1. Run JShell
2. Attach HSDB to JShell
$ jhsdb hsdb --pid
3. Select "Monitor Cache Dump" in "Tools" menu.
ObjectSynchronizer$ObjectMonitorIterator switches monitor block list
when
On 8/8/17 1:27 AM, Ujwal Vangapally wrote:
Hi,
below is the link to new webrev incorporating review comments.
webrev:
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.02/
769 * The Behaviour is same as {@link #getThreadInfo(long[], boolean,
boolean)}
770 * except that t
On 8/8/17 10:18 AM, Daniel Fuchs wrote:
That's what will happen if someone had a custom implementation
of ThreadMXBean which is compiled against JDK 9 but runs in JDK 10,
and therefore does not have the new methods. Then it inherits
the default body that throes UOE.
I'm not aware of any cust
Hi Mandy,
On 08/08/2017 18:03, mandy chung wrote:
Throwing UOE would be clearer than throwing UndeclaredThrowableException
and ReflectionException.
That's what will happen if someone had a custom implementation
of ThreadMXBean which is compiled against JDK 9 but runs in JDK 10,
and therefore d
Throwing UOE would be clearer than throwing UndeclaredThrowableException
and ReflectionException.
However MBean proxy simply forwards the call to the remote MBeanServer
and calls invoke or getAttribute/setAttribute. NoSuchMethodException
will be thrown in the remote VM and the client would get
Thanks for the review Daniel.
I also verified Daniel's suggestion, it works fine and it helps in
better backward compatibility.
if it is ok to have a default body in ThreadMXBean interface I will send
a new webrev incorporating that change.
-Ujwal
On 8/8/2017 2:52 PM, Daniel Fuchs wrote:
Hi Ujwal,
I have made a small experiments and it seems that having
a default body doesn't prevent an interface method from
being called from either a JMX or a Platform proxy.
So in the light of this I'll suggest to add a default body
that throw UnsupportedOperationException to the new methods
ad
Hi,
below is the link to new webrev incorporating review comments.
webrev:
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.02/
verified that
MBeanServerConnection.invoke throws ReflectionException when invoked with a
method that doesn't exist in remote MBean server.
Unde
10 matches
Mail list logo