Hi Martin,
On 6/09/2017 4:38 PM, Martin Skarsaune wrote:
Hi
If I run *JFR.check* in build 9+181 , the response indicates that I can
invoke *VM.unlock_commercial_features*.
This command is not available in the given VM.
The output should not refer to this command i VM where it is not availabl
Hi Martin,
In my opinion, the interfaces exposed by current JEP are lot closer to
REST style than the interfaces exposed by Jolokia.
For instance, HTTP GET by default should be used to read resources, but
it is made part of URL in Jolokia interfaces.
/read///
I would wait on opinions from
Hi
If I run *JFR.check* in build 9+181 , the response indicates that I can
invoke *VM.unlock_commercial_features*.
This command is not available in the given VM.
The output should not refer to this command i VM where it is not available.
Cheers
Martin Skarsaune
Example:
Martins-MacBook-Pro-2
Hi JC,
Thank you for verifying this!
On 9/5/17 11:01, JC Beyler wrote:
Hi all,
After looking at the code a bit more, I don't see a viable
way of really either:
- At notification disabli
Hi Harsha,
I wouldn’t consider Jolokia to be an alternative because as I suggested, it’s
not a complete JMXConnector implementation and as such cannot be used with
standard JMX clients such as the MBean viewer in JMC or VisualVM. In my
opinion, it would be super if the product of the JEP could
Hi Kirk,
Yes. Jolokia was considered and is listed as an alternative in the JEP.
* Jolokia can serve as a viable alternative but can be bulky. We are
looking for simple and lightweight solution.
-Harsha
On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote:
Hi,
Have you run int
Hi,
Have you run into this project? https://jolokia.org. Unfortunately it’s not
exactly a drop in replacement for the standard RMI based JMX connector but it’s
not far off.
Kind regards,
Kirk
> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote:
>
> Hi Harsha,
>
> Looping in jmx-dev.
>
> > byte
Hi Erik,
On Tuesday 05 September 2017 10:00 PM, Erik Gahlin wrote:
Hi Harsha,
Looping in jmx-dev.
> byte[], short[], int[], float[], double[]
Should long[] be included there as well?
Yes. Thanks.
> The REST adapter will come with a simple and lightweight JSON parser.
Is this an internal
Sorry for the incomplete answer earlier. There are also
relevant tests in:
jdk/test/java/lang/management
jdk/test/com/sun/management
jdk/test/sun/management
jdk/test/jdk/internal/agent
jdk/test/javax/management
jdk/test/com/sun/jmx
You might want to just run the 'jdk_mana
Thank you Daniel. I will run and update it with the result.
Regards,
Shafi
On Tue, Sep 5, 2017 at 9:44 PM +0530, "Daniel D. Daugherty"
wrote:
Seems like you should also run: nsk.monitoring.testlist
Dan
On 9/4/17 4:11 AM, Sha
Hi Harsha,
Looping in jmx-dev.
> byte[], short[], int[], float[], double[]
Should long[] be included there as well?
> The REST adapter will come with a simple and lightweight JSON parser.
Is this an internal parser or will it be exposed as an API?
If so, how does it relate to JEP 198: Light-
Seems like you should also run: nsk.monitoring.testlist
Dan
On 9/4/17 4:11 AM, Shafi Ahmad wrote:
Hi,
Please review the fix for ‘JDK-8170299: Debugger does not stop inside
the low memory notifications code’ to jdk10.
With the current implementation ‘debugger does not stop inside the low
12 matches
Mail list logo
