TEC607008: IBM J9 JVM 1.6 may throw the exception java.lang.UnsupportedOperationException during Java Agent Initialization when Retransformation is disabled

Document created by Keith.W Employee on May 26, 2016Last modified by J.J. Lovett on May 26, 2016
Version 2Show Document
  • View in full screen mode

Document ID:  TEC607008

Last Modified Date:  3/4/2014
Authored By: Keith.W

  • Products
    • CA Application Performance Management
  • Components
    • INTROSCOPE

 

Description:

IBM J9 JVM 1.6 throws an exception early in application server and agent initialization.
The exception is java.lang.UnsupportedOperationException.

When the application server is WebSphere, the exception appears in the native_stderr.log file.

ENVIRONMENT

The problem has been observed on WebSphere 8.5.5.1 running on AIX 7.1 with IBM J9 JVM 1.6
SR7, together with the AgentNoRedefNoRetrans.jar variant of the Introscope 9.5.5 Java
Agent. Other operating system, J9, and app server combinations may or may not be affected.

TECHNICAL DETAILS

Early in Introscope Java Agent initialization, the agent will interrogate the JVM to determine its instrumentation capabilities. These capabilities include redefinition (for Java 1.5+) and retransformation (for Java 1.6+). The interrogation for both of these capabilities occurs regardless of whether or not they are disabled in the agent jar's MANIFEST.MF via the Can-Redefine-Classes andCan-Retransform-Classes boolean headers.

When Can-Retransform-Classes is set to false -- such as in the AgentNoRedefNoRetrans.jar agent variant - IBM J9 may throw an exception when the agent interrogates the JVM to determine if it supports class retransformation. When the application server in use is WebSphere, the exception appears within the native_stderr.log and looks like the following:

Exception in thread "main" java.lang.UnsupportedOperationException: cannot get the capability, performing dispose of the retransforming environment

at sun.instrument.InstrumentationImpl.isRetransformClassesSupported0(Native Method)
at sun.instrument.InstrumentationImpl.isRetransformClassesSupported(InstrumentationImpl.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.wily.introscope.api.instrument.JavaRedefineRetransformBean.getJavaRedefineRetransformBeanInfo(JavaRedefineRetransformBean.java:147)
at com.wily.introscope.api.instrument.JavaAgent.initializeAgent(JavaAgent.java:234)
at com.wily.introscope.api.instrument.JavaAgent.premain(JavaAgent.java:198)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:335)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:350)

The Introscope Java Agent is calling method getJavaRedefineRetransformBeanInfo() which in turn invokes a JVM method isRetransformClassesSupported() via inflection to determine if class restransformation is supported. Following the stack trace along, it is noted that this invoked call finds its way into native code before the java.lang.UnsupportedOperationExceptionexception is thrown. This is thrown deep within the JVM, outside of Introscope code, and is handled within the JVM in the form of the stack trace. The exception does not make it back into Introscope code to be caught.

The invoked call to isRetransformClassesSupported() occurs within a try block with a subsequent catch that is intended to absorb and log all Throwable objects, i.e., any exception. Despite this the java.lang.UnsupportedOperationException exception is thrown and printed to stderr and does not appear in Introscope Java Agent logs. This implies that the exception never makes it back into Introscope Java Agent code and has been further proven in-house with strategically-placed logging statements sandwiching the isRetransformClassesSupported() invocation. Since the exception does not make it back to Introscope code, the try block commences normally and the Agent code achieves the expected result of isRetransformClassesSupported() -- which is false.

Solution:

The exception is harmless and in no way affects the functionality of the Introscope Java Agent or the monitored application server.

 

Search the Entire CA APM Knowledge Base

 

search-kb.jpg

Attachments

    Outcomes