Details
-
Support Request
-
Resolution: Support Request
-
Low
-
None
-
5.2.5
-
None
Description
We're seeing in our system a build-up of stuck threads all consuming a lot of CPU time:
PID USER S %CPU %MEM TIME+ COMMA 15687 jira S 87.0 27.7 56335:34 java 15688 jira S 87.0 27.7 56335:23 java 15689 jira S 87.0 27.7 56335:47 java 53147 jira S 87.0 27.7 32379:48 java 14885 jira S 87.0 27.7 6:05.59 java 15690 jira S 85.0 27.7 56336:00 java 45110 jira S 85.0 27.7 48109:38 java 45111 jira S 85.0 27.7 48109:21 java 45112 jira S 85.0 27.7 48110:06 java 45113 jira S 85.0 27.7 48109:29 java 53148 jira S 85.0 27.7 32380:16 java 53149 jira S 85.0 27.7 32380:16 java 53150 jira S 85.0 27.7 32379:44 java
All those stuck threads are calling HashMap.getEntry():
"Thread-240279" daemon prio=10 tid=0x00007fc3bf9aa800 nid=0xcf9e runnable [0x000000004b457000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.getEntry(Unknown Source) at java.util.HashMap.containsKey(Unknown Source) at com.atlassian.jira.issue.IssueImpl.getCustomFieldValue(IssueImpl.java:934) at com.atlassian.jira.issue.Issue$getCustomFieldValue$0.call(Unknown Source) at com.onresolve.jira.groovy.jql.LazyCustomFieldsMap.populateCache(LazyCustomFieldsMap.groovy:32) at com.onresolve.jira.groovy.jql.LazyCustomFieldsMap.getValues(LazyCustomFieldsMap.groovy:22) at com.onresolve.jira.groovy.jql.LazyCustomFieldsMap.get(LazyCustomFieldsMap.groovy:59) at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1508) --
We have some JIRA Listeners that are processing events, and checking some Custom Fields for a condition. I seem to recall seeing other concurrency issues that were fixed in the past...maybe this is another one?
Attachments
Issue Links
- relates to
-
JRACLOUD-36773
CPU pegged processes stuck in HashMap in getCustomFieldValue()
-
- Closed
-