Our Dynatrace agent causes problems with Confluence 5.10.8

[Tom Jackson]

We have been using a dynatrace agent with our Confluence server for the past three years for monitoring our JVM. It attaches via the JVM -agentpath argument. We recently upgraded from Confluence 5.8 to Confluence 5.10. The upgrade went fine but Confluence regressed. Searches worked fine but all page views failed (with HTTP "Page Not Found" errors). After much muddling we root caused to our Dynatrace agent (removing agent cleared all symptoms).

We are running Confluence on 64-bit Windows as a Windows service.

To re-iterate:

• Our Dynatrace setup with Confluence 5.8 and earlier works fine
  • the agent is configured via Java Options key in the Windows registry
• With Confluence 5.10, the Dynatrace agent works fine, but Confluence throws errors when users view pages

Has anyone else run into compatibility problems between Confluence 5.9+ and Dynatrace?

The specific conflict appears to lie with the com.atlassian.confluence.pages.actions.PageAwareInterceptor class in Confluence. Anytime we attempt to view a page in Confluence, we get an error like this:

2017-03-07 12:08:08,370 ERROR [http-bio-443-exec-18] [[Standalone].[localhost].[/].[action]] log Servlet.service() for servlet action threw exception
-- referer: https://confluencedev.nordstrom.net/dosearchsite.action?cql=lastmodified+%3E%3D+%222014-05-01%22+and+lastmodified+%3C%3D+%222017-03-07%22+and+type+%3D+%22page%22 | url: /display/TDS/NPS+Consumer+Reference+Links | traceId: 20b87a6f46e04a7b | userName: X0OX
java.lang.IllegalAccessError:
at com.atlassian.confluence.pages.actions.PageAwareInterceptor$$dtt.dt_41_intercept_61(Unknown Source)
at com.atlassian.confluence.pages.actions.PageAwareInterceptor.intercept(PageAwareInterceptor.java:50)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.spaces.actions.SpaceAwareInterceptor.intercept(SpaceAwareInterceptor.java:71)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165)
at com.atlassian.confluence.security.interceptors.ConfluenceAccessInterceptor.intercept(ConfluenceAccessInterceptor.java:31)

[chucktalk]

Hi Tom,

Dynatrace offer the following information from https://community.dynatrace.com/community/display/DOCDT62/Apache+Tomcat

<quote>

In a 64 bit Atlassian Confluence installation setenv.sh already exists in CATALINA_BASE/bin , in this case equivalent to CATALINA_HOME/bin and <ConfluenceProgramDirectory>/bin and you must extend CATALINA_OPTS with e.g.:

CATALINA_OPTS="$CATALINA_OPTS -agentpath:/opt/dynatrace-6.2/agent/lib64/libdtagent.so=name=Tomcat,server=<CollectorName>"

</quote>

Hope that helps sir. Not sure which version you are using of Dynatrace.

Sincerely,

Chuck Talk

[Tom Jackson]

Thanks Chuck, I added some clarification to my problem report. Does that help?

[chucktalk]

Hi Tom,

It may be the registry key that is the issue if that is associated with the Service. I am not a Dynatrace expert, but the page: https://community.dynatrace.com/community/display/DOCDT62/Apache+Tomcat does specifically mention setting up Tomcat as a Windows Service, and specifically states:

<quote>

If all fails, check for the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Tomcat<version>\Parameters\Java.

</quote>

I suspect, though I am not certain of this, that they may mean that the registry key would need to be removed from the Windows server so that a new service can be registered by recreating the Windows Service on the Server. 

The reason I suspect that is that the pre-existing registry key is likely associated with the previous Windows Service, and the upgraded instance is technically a new service when the application was upgraded.

Recreating the service as outlined on their page after removing the Registry Key may resolve this issue for you and allow you to continue to use the Dynatrace agent.

However, I am not a Dynatrace Expert, and you may wish to speak with their Support in order to confirm that fact as well. 

If you have a staging environment, I would recommend testing this on that environment before attempting the change in production.

I hope that information is helpful Tom.

Sincerely,

Chuck Talk