Friday Oct 24, 2008

Early Access 4 of the Web Services Connector for JMX is out

You can download it from ws-jmx-connector.dev.java.net.

The changes since the early access 3 are detailed in the release notes.

The major improvement is related to the JMX-to-XML mapping of CompositeData and TabularData. We have defined a much more compact representation that makes exchanged messages up to 3 time smaller.

To better address non Java clients we have added a taglet to help you generate the information that a pure WS-Management client would need to interoperate with your JMX application. An example of this taglet usage is provided. It covers all the tasks required to make VBScript to interoperate with an MBean, from MXBean interface development and documentation to VBScript writing.

In addition, a set of new VBScript samples provide some concrete examples of interoperability.

You can send us your feedback on users@ws-jmx-connector.dev.java.net

Regards

Jean-François Denise

Friday Jul 11, 2008

VBScript XML processing to extract JMX content

In a previous post I have presented the details of the VBScript script used to interact with a JMX application in which a Web Services Connector was deployed.

In order to deal with XML namespaces, I wrote a really horrible function based on the knowledge of the namespace prefix name computation. Something that I presented as a very bad way, caused by my lack of expertise in VBScript.

Since this previous post, I have written a bunch of scripts and dived into some VBScript librairies details. I have found the right way to process XML and deal with Namespaces. This is done thanks to XPATH usage. By setting a set of properties on the object returned by CreateObject("Microsoft.XMLDOM"), you can inject prefix/namespace associations. These associations are then usable when selecting XML nodes.

Retrieving the WS-Enumeration enumeration context of an MBean subscription

WS-Man session creation and subscription invocation is detailed in the previous post. The enumeration context must be extracted as follow:
set reply = ...

Dim objXMLDoc
set objXMLDoc = CreateObject("Microsoft.XMLDOM")

' Make the reply to be loaded synchronously
objXMLDoc.async = False

' Load the reply 
objXMLDoc.loadXML(reply)

' Make XPath the selection dialect
objXMLDoc.setProperty "SelectionLanguage", "XPath"

' Associate "wsen" prefix to WS-Enumeration namespace.
objXMLDoc.setProperty "SelectionNamespaces", "xmlns:wsen='http://schemas.xmlsoap.org/ws/2004/09/enumeration'"

' There is a single enumeration node, selectSingleNode returns the first one.
Dim node
set node = objXMLDoc.selectSingleNode("//wsen:EnumerationContext")

' node.text contains the enumeration context value
dim enumContext 
set enumContext = node.text

Retrieving the MBean Notifications pulled from the server

Notification pulling is detailed in the previous post. Extracting all the Messages contained in the list of notifications is done as follow:
set reply = ...
dim replyXml
set replyXml= CreateObject("Microsoft.XMLDOM")
replyXml.async = False
replyXml.loadXML(reply)

' Make XPath the selection dialect
replyXml.setProperty "SelectionLanguage", "XPath"

' Associate "jmx" prefix to JMX Web Services Connector namespace.
replyXml.setProperty "SelectionNamespaces", "xmlns:jmx='http://jsr262.dev.java.net/jmxconnector'"

' Select all the Notification Message nodes text values
set msgList = replyXml.selectNodes("//jmx:TargetedNotification/jmx:Message/text()")

' Display the Messages
for i = 0 To (msgList.length - 1)
    set msg = msgList(i)
    ' Display the notification message
    WScript.echo "Notification : " & msg
next

Conclusion

VBScript API to extract XML content is efficient and simple to use. It is very helpful when extracting values from complex data structures (such as CompositeData or MBeanInfo). Obviously its usage is much wider than JMX interoperability.

Hope this help.

Jean-François

Tuesday Jun 03, 2008

RESTful Access to JMX Instrumentation, second part

This post is an answer to William Vambenepe who recently wrote an interesting post related to JSR 262 and the REST access to JMX I discussed a few months ago. William shows some interest in the REST adaptor for JMX and asks for the next steps. Here they are...


A bit of context

The REST approach is a possible solution for interaction with JMX agents mostly due to the fact that monitoring and management is increasingly present in our systems at a much higher level than it used to be.

The data exposed tends to be directly understandable. There is no need for complex processing on the client side to understand what is going on. Why is this possible? I think that it comes from the fact that the new trend in Monitoring and Management consoles (consoles such as JConsole or Visual VM), is to display "raw" data.

This raw data is interpreted by only viewing or displaying it graphically. It makes MBean designers think more and more about their MBean interfaces as human-readable APIs. My colleague Daniel Fuchs shows the limits of this approach in a recent blog entry. But I also remember Daniel saying a few years ago that people will soon start to design MBeans to comply with JConsole's capabilities. I think that he was absolutely right. This is what is emerging now.


So it seems an appropriate time to build an HTTP based access, along standardized lines, to allow web designers to benefit from this valuable management information by making it possible to embed it directly in Web pages.


My previous post put in place the foundations of the REST adaptor for JMX agents. This post covers the next features that should be added in the near future. I write “should be added” because I would like to hear your reactions to them before I add them to the current implementation. Please let me know whether or not they will meet any of your requirements, so that we can discuss how to improve them. The adaptor will be much more valid if it answers the needs of the community.


Security

HTTPS and Basic AUTH seem natural choices. Nothing special, simple and safe. They should cover most cases. Is Basic AUTH enough or do we also want to offer “mutual authentication”, to allow the server to authenticate clients based on client certificates? What about access control? We could easily add access control based on JMX permissions as is done today when you provide an access and password file when starting the JVM.


Snapshot of values

Currently we can't retrieve a complex MBean attribute atomically. Say that we want to retrieve all the values contained in the HeapMemoryUsage attribute of the Memory MBean. This attribute is of type CompositeData. The well-known URLs (that point to plain text data) associated to this attribute are the following:


http://curcuma:9999/rest/jmx/java.lang:type=Memory/HeapMemoryUsage/committed

http://curcuma:9999/rest/jmx/java.lang:type=Memory/HeapMemoryUsage/init

http://curcuma:9999/rest/jmx/java.lang:type=Memory/HeapMemoryUsage/max

http://curcuma:9999/rest/jmx/java.lang:type=Memory/HeapMemoryUsage/used


Currently, we can only retrieve committed, init, max and used individually.

If we introduce a new query parameter named capture, we could ask the adaptor to construct a frozen view of an attribute value (or more generally of a sub-tree). We could then retrieve the values located in the snapshot.


In practice:

GET http://curcuma:9999/rest/jmx/java.lang:type=Memory/HeapMemoryUsage?capture=mysnapshot1


Returned resource :

<ul>
<li>http://curcuma:9999/rest/snapshots/mysnapshot1/jmx/java.lang:type=Memory/NonHeapMemoryUsage/commited</li>
<li>http://curcuma:9999/rest/snapshots/mysnapshot1/jmx/java.lang:type=Memory/NonHeapMemoryUsage/init</li>
<li>http://curcuma:9999/rest/snapshots/mysnapshot1/jmx/java.lang:type=Memory/NonHeapMemoryUsage/max</li>
<li>http://curcuma:9999/rest/snapshots/mysnapshot1/jmx/java.lang:type=Memory/NonHeapMemoryUsage/used</li>
</ul>



The returned URLs reference the captured data. We now have the freedom to analyze the values outside the ever-changing real world. This pattern could also be applied higher up in the tree (at the MBean level, for example) to create a snapshot of multiple attributes.


Notifications

We could map from JMX Notifications to atom feeds. This could be a good approach. However, here I would like to keep it simple and carry on with the resource-centric approach and try not to break the model. I would like to make the number of required technologies as minimal as possible. Relying on HTTP(S) with a bit of HTML/XML should be the maximum we allow ourselves... ;-)


So, how can we proceed? JMX MBeans are the event sources. Clients generally subscribe to MBean notifications then pull notifications from the MBean server. Pulling seems very appropriate in our web context. Pushing has never really worked.

If you want reliable, zero-loss notifications then you should stop reading this post. You are going to be frightened by what I am about to say. In JMX we generally see notifications as an unreliable way to receive information. You can't count on a high level of reliability. Lost notifications are not common but they can occur. Once you know the context in which notifications are handfed, you can design an event system that copes with it. Making your MBean re-emit notifications until an acknowledgement comes back can be a decent solution.


If we agree with what has been said previously, we can attach a rolling buffer to each MBean resource that contains the last n emitted notifications (10 is a possible default value). This buffer can be pointed to using the URL scheme we have already put in place.

Here is an example URL for retrieving notifications:

http://curcuma:9999/rest/notifications/jmx/java.lang:type=Memory/



If events occur, the list of emitted notifications is returned in the GET response.

<ul>
    <li>
       Notification 1 
    </li>
    <li>
       Notification 2
    </li>
    ...
    <li>
       Notification N
    </li>
</ul>

Representation of notifications

A Notification is a complex type for which we can define a set of well known URLs. By nature, a notification is a snapshot of data, and its URL contains the information that makes it unique. The JMX API doesn't guarantee a unique sequence number. The emission time seems a better identifier.


<ul>
  <li>http://curcuma:9999/rest/notifications/jmx/java.lang:type=Memory/25_12_1970_12_00_00/message</li>
  <li>http://curcuma:9999/rest/notifications/jmx/java.lang:type=Memory/25_12_1970_12_00_00/number</li>
  <li>http://curcuma:9999/rest/notifications/jmx/java.lang:type=Memory/25_12_1970_12_00_00/type</li>
  <li>http://curcuma:9999/rest/notifications/jmx/java.lang:type=Memory/25_12_1970_12_00_00/userdata/<...possible path if complex type></li>
   ... user data URL continue if complex content.
</ul>

Custom notifications

If the emitted notification is custom-built, and some getters are exposed, then the added field is discovered and exposed. For example, the following notification defines a getPriority field:


public class PriorityNotification extends Notification {
  ...
  public int getPriority() {
    ...
  }
}

This will be returned as follows:

<ul>
 <li>http://curcuma:9999/rest/jmx/notifications/java.lang:type=Memory/25_12_1970_12_00_00/priority</li>
 <li>http://curcuma:9999/rest/jmx/notifications/java.lang:type=Memory/25_12_1970_12_00_00/message</li>
 <li>http://curcuma:9999/rest/jmx/notifications/java.lang:type=Memory/25_12_1970_12_00_00/number</li>
 <li>http://curcuma:9999/rest/jmx/notifications/java.lang:type=Memory/25_12_1970_12_00_00/type</li>
 <li>http://curcuma:9999/rest/jmx/notifications/java.lang:type=Memory/25_12_1970_12_00_00/userdata/<...possible path if complex type></li>
</ul>



Filtering based on emission time

You could argue that only keeping 10 notifications is insufficient and that all notifications should be stored. OK, but in this case, we would like to be able to filter out the old ones. That can be done by adding a since query parameter when getting notifications. For example:

http://curcuma:9999/rest/notifications/jmx/java.lang:type=Memory/?since=20_12_1970_00_00

We just need to agree on a date format.

Notification retrieval scope

This approach allows us to express a homogenous "retrieval scope”. By choosing a location in the tree (a URL where we can get notifications), we can retrieve notifications emitted by :

  • MBean servers (all MBeans, and potentially all attributes too, could add a JMX pattern to narrow the scope)

  • MBeans

  • MBean attributes (equivalent to AttributeChange).

  • Information inside an attribute value (namely, is it a real scope, and do we want it?)



Conclusion

It seems that things are still being kept simple here without compromising the JMX technology's philosophy. Or perhaps not, and you think it is already too complicated and I should stop mining this seam... just let me know and I will down tools! ;-)

What do we have on the plate for the next post? Setting attributes and invoking MBean operations. If you have some ideas, please let me know. They are tough ones!

Thanks.

Jean-François Denise

jean-francois.denise@sun.com



Monday Feb 18, 2008

Web Services Connector for JMX enters Public Review

The JSR 262 has just entered the Public Review phase. The Early Access 3 of the Connector, that implements the Public Review, can be downloaded from http://ws-jmx-connector.dev.java.net.

Specification changes since Early Access 2:

  • PUSH mode supported for notifications. This is specified in the client by including JMXWSDefinitions.JMX_WS_NOTIFICATION_PUSH_MODE_URL in the Map given to JMXConnectorFactory.connect. Some related Map entries on the client and server configure security. A new interface JMXWSCredentialsProvider specifies how the connector server gets the credentials it needs to connect to any given client and push notifications.

  • New JMX types supported for MBean operations: NotificationResult, NotificationFilterSupport, AttributeChangeNotificationFilter, MBeanServerNotificationFilter. This allows the JSR 262 connector to support the new Event Service being defined by JSR 255, which has MBean operations that use those types. We also added support for java.lang.Enum and java.util.Set.

  • Connection identifiers supported consistently with the JMX Remote API (JSR 160) specification. This was already alluded to in the Early Draft 2 but is now formalized consistently.

  • Removed the interface JMXWSManResourceHandler. This was a halfway house between the Connector and Adaptor models. The model now is that for a Connector (client sees the JMX Remote API), the protocol is completely specified and invariable.

  • Some minor reshuffling of static final fields between JMXWSConnectorServer and JMXWSDefinitions.

  • The getMBeanInfo operation is now mapped as a Custom Action. Previously the MBeanInfo was a property of the MBean resource, alongside all the attributes of the MBean. This mix of data and metadata was strange.

  • JMXAuthenticator.authenticate method. The passed Object parameter used to be a String[2]. It is now a String[3]. The third element contains a client certificate in case HTTPS Mutual authentication is enabled (null otherwise).

  • XML Element NotificationLost has been removed from the schema. WS-Management already offers such definition by the mean of DroppedEvents XML element. NotificationLost was a redundant redefinition.

  • The schema has been updated, mostly to reflect the changes above, and some minor refactoring.

Implementation changes since Early Access 2:

  • Leverage of the Metro stack components (as detailed in my previous blog entry) in order to increase interoperability and efficiency of the Connector. We are currencly observing a \*3 increase in performance.

  • Rely on the latest JAX-WS 2.1.3 release.

  • Introduction of an adaptor API that allows you to change the way MBeans are exposed in the WS-Management world (javadoc is bundled in the Early Access 3 auto extractible jar under docs directory).

The document that covers interoperability with Microsoft WinRM tooling (winrm command line, VBScript API and Event Viewer support for WS-Management events) has been updated in order to reflect the Public Review changes.

Feedbacks on the specification can be sent to jsr262-spec-comments@sun.com. Feedbacks on the connector implementation can be sent to users@ws-jmx-connector.dev.java.net.

Thanks.

Jean-Francois Denise

Monday Feb 11, 2008

Up the Metro stack to JMX Technology: A Wise Man's Journey

Up the Metro stack to JMX Technology: A Wise Man's Journey


What a long trip... We started by driving on the HTTP highway, slid on SOAP, turned left at the XML crossroads, passed over the WS-Addressing bridge, visited WS-Enumeration, WS-Eventing and WS-Transfer, got a bit lost in WS-Management country, discovered that JMX was not so far off, and finally took a rest (but not a RESTful one) in the Web Services Connector... Did we do all that on our own? No, we did it with a set of friends, the Metros, or the high-performance, extensible, easy-to-use web service stack.


OK, I guess you get it. This little journey lists the set of standards that have been pressed into service to expose JMX MBeans as WS-Management resources. Luckily we didn't have to implement them all. The JAX-WS (a core Metro component) and WiseMan (a WS-Management Java implementation) projects have been of great help.

Now Sun has announced that the WiseMan project is to become part of the Glassfish community. So, it seems to be an appropriate time to look at how the Web Services Connector for JMX Agent RI makes use of WiseMan and Metro.


In this article, I will describe how we changed WiseMan to use part of the Metro stack, what the benefits were, and finally how these technologies are leveraged in the Web Services Connector for JMX Technology

Moving WiseMan to the Stack

In 2007, some significant engineering tasks were undertaken in the WiseMan project to bring the benefits of Metro to WiseMan. This section outlines the steps that were needed to make this move a reality.

The details of this technology switch are of interest to anyone who wants to make their existing applications benefit from Metro's features.

From Servlet to JAX-WS 2.0

WiseMan, was, in its pre-1.0 release, closely coupled with Servlet. At the time, Servlet container was the only way to deploy a WiseMan-based application. We decided to add a JAX-WS Endpoint to the WiseMan project and suddenly we found we could be much more agile. Deployments like the Java SE and Java EE platforms became possible. What a change! For example, being able to base our test suite on the lightweight HTTP server bundled with JAX-WS made our lives much easier...

The JAX-WS Endpoint we developed is a Provider<SOAPMessage>. Simply annotating with @WebService was not possible. WS-Addressing makes intensive use of SOAP headers to convey part of the protocol information. To access to such headers, we need full access to the SOAP Message. After some redesigning of the existing code we extracted a WSManAgent Class that is accessible from a JAX-WS Endpoint or a Servlet.

We took this opportunity to switch to the JAXB release contained in Metro.

So we were happy and impatient to move forward. We already knew that the JAX-WS team was working on adding WS-Addressing support and were waiting for it eagerly.

From JAX-WS 2.0 to JAX-WS 2.1

JAX-WS 2.1 comes with support for WS-Addressing. It's a very smart integration. By just using annotations, your Endpoint becomes addressable thanks to WS-A.

The @Addressing annotation that you can use to tag your Endpoint implies that the WS-Addressing 1.0 release is to be used. However, WS-Management requires the use of another release of the WS-A standard, which is a great pity. We discovered that we were not able to leverage this support. We were afraid this was the end of the road, but the JAX-WS engineering team came back to us showing us the Metro specific API. We were not the first customer with a dependency on a Membership Submission and they defined another “non standard but supported” Annotation to express our requirement : com.sun.xml.ws.developer.MemberSubmissionAddressing

With this annotation added, we removed all the code related to WS-A request-response headers.

So we were happy...but not for long. Our great friends Yves and Sandra of the JMX QA team started to develop some simple stress tests and we started to discover horrible things...

From SOAPMessage to Message

We discovered that 80% of the time spent handling a request was spent in the DOM/SAAJ layer. That's 80% of some big numbers, too...

You remember? Our Endpoint is a Provider<SOAPMessage>. This means that when called, a SOAPMessage object is injected and a SOAPMessage object is expected as the returned value. So we were either stuck, or we had to re-implement the SOAP layer to rely on the STAX API, or we were left with our disapointing figures.

Could the Metro API solve this issue? Yes, the Metro API solved this issue. Once again we were not the first customer, etc., etc., etc. As a solution, an efficient implementation of SAAJ, that is very well integrated with JAXB, is exposed as the Message API (located in the com.sun.xml.ws.api.message package). In order to benefit from its power, you must completely forget all the development you have done on top of SAAJ and rewrite everything on top of this new API. Which is exactly what we did. OK, we re-designed it to make both approaches live together nicely, but we also designed a new API for WiseMan, that was completely isolated from SAAJ. And things started to work much faster (3 to 4 times quicker). The numbers were becoming acceptable, for this kind of XML based processing.


Current WiseMan Architecture




The diagram above shows the different products that are used to build the WiseMan stack on the client and the server. You can see that the WiseMan client stack doesn't rely on Metro, yet. A work-in-progress aims to define and implement such a move, which will greatly improve performance and ease of use.

Improvements for the WiseMan Project

This move helped the project to:

  • Improve deployability

  • Improve alignment and reuse

  • Improve interoperability

  • Improve performance

Deployability, interoperability and performance are the key words of the Web Services Connector for JMX Technology. Based on these new capabilities, WiseMan is becoming the WS-Man implementation of choice for the Web Services Connector for JMX.

When using this connector you are not directly in contact with the stack but you indirectly benefit from the properties you are interested in.


Web Services Connector for JMX Continues Leveraging Metro

This section looks at how the the Web Services Connector for JMX Technology continues leveraging Metro.

Fast Infoset

- "Increase performance!"

- "Increase performance? Hmm..."

Simple, use Fast Infoset! It comes with the stack, it's efficient, it doesn't break interoperability and it's easy to use. We did it and we experienced another big improvement. To enable Fast Infoset in your client API, access the BindingProvider and provide a Fast Infoset key to the request context. For example:

BindingProvider provider = (BindingProvider) port;

Map<String, Object> requestContext = provider.getRequestContext();

requestContext.put("com.sun.xml.ws.client.ContentNegotiation", "pessimistic");

Dispatch<Message> on the client side.

On the client side of the connector, we use the JAX-WS Dispatch class. A Dispatch instance can be seen as an Endpoint proxy that deals with the complete SOAP Message (as opposed to classical JAX-WS proxies that expose a service level API). Since JAX-WS 2.1, Dispatch also handles WS-Addressing. Using Metro specific API, we are creating an efficient Dispatch that is compliant with the WS-Addressing Membership Submission release.

The following code extract shows how to create a Dispatch<Message> for Membership Submission:

Dispatch<Message> port = service.createDispatch(JMXWSConfiguration.JMX_WS_CONNECTOR_PORT, Message.class, Service.Mode.MESSAGE, new MemberSubmissionAddressingFeature(true, true));

Endpoint on the client side

WS-Management defines a way for a WS-Management Agent to deliver its Events in a PUSH mode. This delivery mode implies that the event sink (the client) is itself an Endpoint. We deploy a JAX-WS Endpoint (Provider<Message>) inside our connector client to receive pushed events.

WS-A EndPointReference API

The JMX Web Services Connector RI exposes a non-standard API to customize the mapping of MBeans to WS-Management resources. In this API, we allow customers to hook their customization as low as the WS-Management protocol itself. We needed a WS-Addressing Endpoint reference to expose.

The JAX-WS class javax.xml.ws.EndpointReference offers a standard 1.0 representation that we are internally translating into a Membership Submission via the Metro API (using the class com.sun.xml.ws.developer.MemberSubmissionEndpointReference).

Security

JAX-WS offers support for HTTP Basic Authentication and HTTPS. We are leveraging both.

HTTP Basic Auth

You provide the credentials to a Dispatcher via the request context. The following code extract shows how to provide your credentials.

BindingProvider provider = (BindingProvider) port;

Map<String, Object> requestContext = provider.getRequestContext(); requestContext.put(BindingProvider.USERNAME_PROPERTY, “user); requestContext.put(BindingProvider.PASSWORD_PROPERTY, “password”);

Server Side Security

The way you secure the server side depends on the container in which the Connector is deployed. For more details about how to use the HTTP server bundled in Metro, check the HTTP server API documentation.

Current Web Services Connector Architecture




Interoperability

Based on this architecture, we performed interoperability testing with WinRM (Microsoft's WS-Management based set of tools and API).

This document sums up the scenarios we are testing.

We didn't experience any problems related to interoperability.

Conclusion

Choosing Metro was definitely the right choice. On nearly all levels it has offered the features we were hoping for. When the boundaries of the standards were reached, Metro-specific API entered the scene and offered a solution. Metro really is ahead of the field in terms of improving performance.

So who is the wise man? The ones who defined such long stacks? No, I don't think so....

But Glassfish could be. Its management and monitoring features are based on JMX technology.

So?

So, by deploying the Web Services Connector for JMX (for which the Public Review specification and Early Access 3 RI will be available mid-February) in a Glassfish Server, all the existing MBeans (such as those defined by AMX, by JSR 77, and by you) are automatically exposed as WS-Management resources.

You can imagine the long journey we went through. Would you want to do this on your own, to expose your tiniest resources?

Be wise and use JMX, let us fill in the gaps!

Jean-François Denise

PS: My sincere thanks to Jitendra and Rama from the JAX-WS team for their help. Special thanks to Stuart Clements, my personnal editor and grammar checker.

Friday Dec 07, 2007

JConsole to isolate the Memory leak case

In this blog entry I want to provide you with a tip in order to help you answer to the fact that there is or not a memory leak in your application.

In some cases, where you are instantiating a lot of objects in a very short period of time, you can observe some huge memory consumption making the application to run out of memory. When it happens, we are (too?) quickly identifying this problem as a Memory leak and forget that the application can have reached some badly set JVM memory threshold causing OutOfMemory exception.

In order to distinguish between theses cases, I am using JConsole in a very very simple and quick way.

Steps to follow to isolate the case

1) Keep the JVM activity below the OutOfMemoryException to occur. For example, if your server crashes after 10000 received requests, tune your test case to deal with only 5000 requests. Doing so you will not run out of memory.

2) Start the application you want to monitor.

3) Start JConsole and attach it to your application. If your are using NetBeans, click on the "Run Main Project with Monitoring and Management" toolbar button.

Your project is compiled, run and JConsole automaticaly attached to it.

4) Click on JConsole Memory Tab and call Perform GC button located on the top right corner. The memory consumed during the application startup is released.

5) Start the activity (start a client application that will connect to the server, call a JMX MBean that initiates some activity, ...). Thanks to JConsole you will follow the memory allocation. Some big numbers can be reached there. In the example below, my server is simply serving simple Web Services Request. The memory consumed reaches 200 Megs...

6) Once the activity is stopped, you will notice that the amount of consumed memory is still very high. Call Perform GC multiple time to make sure that the GC is actually freeing the consumed memory.

7) Now you have 2 cases, or the memory consumed number is similar to step 4 and you are not experiencing a memory leak, or it stays high and you found a memory leak. In this example, the memory consumption is high but is not linked to any memory leak. You will notice that the Old Generation Memory pool (last vertical bar on top of Heap label) is cleared. There is no accumulation. In case of memory leak, you would have seen that this pool contains some objects. Mandy Chung wrote a blog entry that describes such case.

You can now take the right action. Or you allocate more memory for your application (use -Xmx JVM option for example), or you start investigate your problem (eg: by using NetBeans Profiler).

Jean-François

Monday Dec 03, 2007

NetBeans 6.0 JMX new features

NetBeans 6.0 is out. You should go experience the new Editor, really amazing... What does it add compared to the previous one? Well... not a lot of things... It simply anticipates your coding, checks your coding and drives you to write better code...no more than that... Kudo to the NetBeans team!

JMX module is part of the game and still downloadable from the stable update center. I am pasting a screenshot of the new update center UI that you now find in NetBeans 6.0.




In this blog entry I am focusing on JDK 6.0 JConsole related new features. You can access to the list of features, latest tutorials, documentation and known issues from this web site : http://management.netbeans.org/jmx.

JConsole to Monitor J2SE Project

If you are used to the JMX module, you will notice that the way to connect JConsole to your J2SE Project has not changed.

Just set your J2SE Project as the “main project”and click on this toolbar button:


Your project will be compiled, run and JConsole will attach to it. The way to setup JConsole and the Monitoring & Management features of your project has changed. The next chapter shows you how to achieve such configuration.

Better integration in J2SE project

Right click on your Project to access the project properties. You will notice a “Monitoring and Management” section. This is your configuration entry point.




From there you can:

  • Enable / Disable JConsole auto attachment.

  • Change JConsole polling period.

  • Use (or not) the project classpath to make JConsole findout your MBean custom handled types. Unselecting this option will show you that you introduced some custom types that imply deployment of these classes on the JMX client application. Having custom types handled by your MBean interfaces is not something that we encourage and this is something that you can simply avoid by using MXBean

  • Lookup the Project Classpath to load JConsole custom plugins. A new JConsole API has been defined in order to allow you to develop custom JConsole tabs and have them added to the list of tabs. The next chapter cover this feature. This article describes JDK 6.0 JConsole plugins new feature.

  • Explicitly add paths to your JConsole plugins jar files or classes.

  • Enable or disable Remote RMI access. By default, remoting is not enabled.

      • You can provide the RMI port the server will listen to. Doing so, you will start a non secure remote access.

      • Or you can provide a path to a management.properties file in which you can configure security.

New Support to load JConsole custom tabs

To do so, simply add JConsole plugins that you downloaded or developed, to the Monitoring and Management Properties Plugins Path list.

In this example, I am adding the JTop plugin that is bundled with JDK 6.0 (<java home>/demo/management/JTop/JTop.jar). This plugin demonstrates the use of the java.lang.management API to obtain the CPU consumption for each thread.

Add the plugin to the Project properties and run your application

In the “Monitoring and Management” Properties :

  1. click on Add Jar/Folder button then provide a path to JTop jar file. The jar file is added to the list.

  2. Close the project properties.

  3. Run your project with by clicking on the JConsole toolbar button.

JConsole is started, JTop tab being loaded and displayed.




Some interesting JConsole plugins


JConsole to Monitor any Java project

If you want to connect JConsole to another kind of Java project (e.g.: Web Application), you can start JConsole and connect it to the application server running your application. To do so click on the following toolbar button to launch JConsole management console:




You can tune the JConsole default Target (default URL to connect to), polling period, plugins path, classpath, arguments or JVM arguments from the NetBeans Options. To do so:

  1. Select Tools | Options from the main menu

  2. Select Miscellaneous tab

  3. Select JConsole tab

The following window is displayed:




Hope to have helped you discover a useful new feature of the JMX tooling.

Regards.



Jean-François Denise

(jean-francois dot denise at sun dot com)

About

jeanfrancoisdenise

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today