java.lang.UnsupportedOperationException: Current thread CPU time measurement is not supported.

Question

Hello Community,

I've been using a very old version of JIRA, and only today updated to 7.9.2.

I am hosting Jira myself since I started using it, and my server runs on NetBSD/amd64 7.1.2 with the latest OpenJDK 8 available through pkgsrc.

Up until this update it was never a problem starting and accessing Jira, but since the update, I get the following error when I try accessing it via web-browser:

java.lang.UnsupportedOperationException: Current thread CPU time measurement is not supported.
	at sun.management.ThreadImpl.verifyCurrentThreadCpuTime(ThreadImpl.java:210) [?:1.8.0_162-internal]
	at sun.management.ThreadImpl.getCurrentThreadUserTime(ThreadImpl.java:276) [?:1.8.0_162-internal]
	at com.atlassian.jira.servermetrics.RequestMetricsCollector.getCurrentThreadUserDuration(RequestMetricsCollector.java:144) [classes/:?]
	at com.atlassian.jira.servermetrics.RequestMetricsCollector.started(RequestMetricsCollector.java:43) [classes/:?]
	at com.atlassian.jira.servermetrics.NestedRequestsMetricsCollector.startCollectionInCurrentThread(NestedRequestsMetricsCollector.java:33) [classes/:?]
	at com.atlassian.jira.servermetrics.MultiThreadedRequestMetricsCollector.startCollectionInCurrentThread(MultiThreadedRequestMetricsCollector.java:26) [classes/:?]
	at com.atlassian.jira.servermetrics.RequestMetricsDispatcher.startCollection(RequestMetricsDispatcher.java:56) [classes/:?]
	at com.atlassian.jira.servermetrics.MetricsCollectorFilter.lambda$startCollection$0(MetricsCollectorFilter.java:32) [classes/:?]
	at java.util.Optional.map(Optional.java:215) [?:1.8.0_162-internal]
	at com.atlassian.jira.servermetrics.MetricsCollectorFilter.startCollection(MetricsCollectorFilter.java:32) [classes/:?]
	at com.atlassian.jira.servermetrics.MetricsCollectorFilter.doFilter(MetricsCollectorFilter.java:24) [classes/:?]
	at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:32) [atlassian-core-5.0.8.jar:?]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192) [catalina.jar:8.5.6]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) [catalina.jar:8.5.6]
	at com.atlassian.jira.web.filters.steps.ChainedFilterStepRunner.doFilter(ChainedFilterStepRunner.java:74) [classes/:?]
	at com.atlassian.jira.web.filters.JiraFirstFilter.doFilter(JiraFirstFilter.java:57) [classes/:?]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192) [catalina.jar:8.5.6]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) [catalina.jar:8.5.6]
	at com.atlassian.gzipfilter.GzipFilter.doFilterInternal(GzipFilter.java:115) [atlassian-gzipfilter-3.0.0.jar:?]
	at com.atlassian.gzipfilter.GzipFilter.doFilter(GzipFilter.java:92) [atlassian-gzipfilter-3.0.0.jar:?]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192) [catalina.jar:8.5.6]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165) [catalina.jar:8.5.6]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) [catalina.jar:8.5.6]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:108) [catalina.jar:8.5.6]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) [catalina.jar:8.5.6]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) [catalina.jar:8.5.6]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [catalina.jar:8.5.6]
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620) [catalina.jar:8.5.6]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349) [catalina.jar:8.5.6]
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:784) [tomcat-coyote.jar:8.5.6]
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-coyote.jar:8.5.6]
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802) [tomcat-coyote.jar:8.5.6]
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410) [tomcat-coyote.jar:8.5.6]
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-coyote.jar:8.5.6]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162-internal]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162-internal]
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-util.jar:8.5.6]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162-internal]

Now, in general, best practice before calling a method like

getCurrentThreadUserTime()

or anything like that, is to call for

isCurrentThreadCpuTimeSupported()

This is at least the quintessence of the JavaDoc, as you can read here.
Excerpt:

Thread CPU time

A Java virtual machine implementation may support measuring the CPU time for the current thread, for any thread, or for no threads.

The isThreadCpuTimeSupported() method can be used to determine if a Java virtual machine supports measuring of the CPU time for any thread. The isCurrentThreadCpuTimeSupported() method can be used to determine if a Java virtual machine supports measuring of the CPU time for the current thread. A Java virtual machine implementation that supports CPU time measurement for any thread will also support that for the current thread.

The CPU time provided by this interface has nanosecond precision but not necessarily nanosecond accuracy.

A Java virtual machine may disable CPU time measurement by default. The isThreadCpuTimeEnabled() and setThreadCpuTimeEnabled(boolean) methods can be used to test if CPU time measurement is enabled and to enable/disable this support respectively. Enabling thread CPU measurement could be expensive in some Java virtual machine implementations.

However, this seems to be ignored here, leading to the case that there are systems (mainly BSD and BSD-like systems), on which Jira will not work anymore.

I have searched the internet and this community a while in order to check if there's already a solution for this, as I am rarely the first to encounter such things. As I didn't find any, I am now posting this, and ask, if anyone here knows a solution - is there an option to disable this collecting of metrics, or is there anything else I can do...I wouldn't want to go back to an older version of Jira, just because of this...

Any help is appreciated, thank you very much!

Volkmar Seifert

Volkmar Seifert · Answer

Thank you for the detailed response.

I do understand that your development team cannot be expected to recreate every scenario a single customer might have. I'm a software developer myself, with about 25 years of professional experience under my belt, so I know these things myself all too well. And I understand how a good bug report should look like.

I will give the linux emulation and official Oracle JDK a try in order to prove my point that this is actually JDK independent. There is a good reason for Oracle to have this passage that I quoted in my original post in their official documentation of the Java API.

Not all platforms, for which an official JDK is available, support the same general features. As Java intends to be "platform independent", you need to reflect that in your coding when using platform specific features.

CPU thread time measuring is such a platform specific feature, and is not available on all platforms for which you can get an (official) JDK.

Please give me a day or two to checkout the latest official Oracle JDK, in order to a) see if I can actually get it working now, and b) if it solves the issue or proves my point.

If it solves the issue, I'll be happy to admit that I was wrong about "the JDK doesn't matter" point and we can close this issue. If it proves my point, I hope we can continue this discussion in order to solve the issue along the way Oracle advises in the offical docs.

About modifying the sources - well, it's nice to know that I am allowed to do this for my own use and purposes, but thank you, no. Jira is too complex a software for someone outside the project to fiddle with the inner workings. That would most certainly break more than it would fix.

Andy Heinzer · Answer

Hi Volkmar,

My intention was not to dismiss your concerns, but rather manage your expectations here.

I appreciate that you want to pursue this issue as a bug in Jira.  I am willing to investigate that route.  However in order for me to create a bug ticket for this specific problem, I need to have a clear set of steps documented to follow to reproduce the problem.

Right now, my list of steps includes using an unsupported platform for Jira.   I can tell you right now that any bug created that requires the environment be using an unsupported platform in order to reproduce the problem is going to get summarily closed with the "invalid" or "Won't fix" resolutions.  This is because there are limits in regards to the types of problems Atlassian can be expected to address in Jira.  We have to focus on the platforms Atlassian has agreed to support moving forward.   As of today, this does not include OpenJDK in regards to using it with Jira.

Please review the Atlassian Bug fixing policy.  It is important to understand that Atlassian will prioritize bugs that do get created based on a number of factors such as complexity, impact to other aspects of the product, the existence of a work-around, severity, difficulty to fix, and number of supported configurations affected by this problem.   Right now, your environment is not even supported by Atlassian.  As such I would not have an expectation of Atlassian to address the problem you have provided here with the information we have now.

I understand this is a frustrating situation to be in.  Your previous version of Jira did not have this problem and it's only after the upgrade that you see this problem.  But just because you had Jira working on an unsupported platform in the past is not justification for Atlassian to support that configuration.

Now, if you can reproduce this same problem in a supported platform for Jira, then great, with the documented steps to follow to recreate this issue, I will generate a bug report and we can go from there.  Maybe this isn't related to the specific JVM as you have suggested.  But if that is the case, then I need to understand specifics about the environment that brought about this error to be able to investigate if this can be filed as a bug or not.   Bug tickets need to have clearly documented steps on how to reproduce the problem.

Alternative to avenue of addressing this issue; you could download the source code for Jira and make these changes yourself.  But I don't think this will be a trivial change to make in the code.

Volkmar Seifert · Answer

Hello, and thanks for responding,

it's pretty easy to dismiss this case as "oh, he's using OpenJDK, tell him to switch", and ignore the fact that this is actually a bug in the software, where best practices were discarded for whatever reasons.

The docs I quoted were directly from Oracle, and they apply to the official JDK even more so than to OpenJDK. The issue I have with Jira as descrived above might therefore very well also occur with the official JDK. As the official JDK uses a couple kernel features that are not available in the linux emulation on NetBSD (I don't know the exact reasons, atm), I cannot verify this, so switching is not really an option anyway.

So, if we could perhaps focus again on the actual issue at hand here, I'd be very thankful, because that would address the actual problem. Switching JDKs would be a mere workaround.

Volkmar