The Jira application is intermittently inaccessible due to the add-on "Color Cards for Jira"

Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

The 3rd party add-on Color Cards for Jira is known to intermittently prevent the Jira application from being responsive nor accessible to its users. This KB article provides a way to verify whether this add-on is the reason for intermittent outages with your Jira application.

Environment

Jira Server / Data Center 8.0.0 and any higher version.

Diagnosis

  • Before the Jira application became unresponsive, we can see in the Garbage Collection logs that the Heap Memory usage rapidly increased without being released, and that the Garbage Collector kept performing full GCs:

    (Auto-migrated image: description temporarily unavailable)

  • In the Tomcat catalina logs (<JIRA_INSTALL>/logs/catalina.out), we can see that an OOM error (out of memory) was triggered and a heap dump was generated around the time the Jira application became unresponsive:

    1 2 3 java.lang.OutOfMemoryError: Java heap space Dumping heap to /opt/jira/application-data/java_pid119627.hprof ... Heap dump file created [13689316420 bytes in 117.154 secs]

  • When analyzing the Heap Dump using a Heap Dump analyser too such as Eclipse Mat tool, we can make the following observations:

    • There is at least one object using a big amount of heap (a few gigabytes):

      (Auto-migrated image: description temporarily unavailable)

    • Checking the threads associated to these 2 objects, we can see that both threads are HTTP threads starting with /rest/cc/1.0/resource

      (Auto-migrated image: description temporarily unavailable)

    • If we check the content of the big objects, we can see that these objects contains a very high number of "search document" objects (for example 50k objects), ultimately contributing to the big size of the object

      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Class Name | Shallow Heap | Retained Heap | Percentage ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- org.apache.tomcat.util.threads.TaskThread @ 0x5a34b2940 http-nio-8080-exec-80 url:/login.jsp ... url:/rest/cc/1.0/resource/colors username:someuser Thread| 120 | 5,101,554,832 | 47.91% '- java.util.stream.ReduceOps$3ReducingSink @ 0x667687350 | 32 | 5,091,670,408 | 47.82% '- java.util.ArrayList @ 0x66eaa30e8 | 24 | 5,091,670,376 | 47.82% '- java.lang.Object[53508] @ 0x66ede6840 | 214,048 | 5,091,670,352 | 47.82% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x61796ae58 | 24 | 373,008 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x6c0afd878 | 24 | 369,040 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x626b47a30 | 24 | 368,784 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x61ce45988 | 24 | 368,584 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x609929f68 | 24 | 368,224 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x6d3ceb1e8 | 24 | 366,920 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x6142091f0 | 24 | 366,584 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x626e06ba0 | 24 | 366,264 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x66a8b3060 | 24 | 365,832 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x6d008f5d8 | 24 | 365,680 | 0.00% |- com.atlassian.jira.issue.search.DocumentWithId @ 0x64f8164f8 | 24 | 365,520 | 0.00% ... - Total: 50 of 49,175 entries

    • Looking at the Stack Trace of one of the thread associated to these big objects, we can see that the class com.ascendintegrated.colorcards which is coming from the 3rd party add-on Color Cards for Jira is called and is performing some heavy Jira search to render the colour of cards based on issue types:

      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 31 http-nio-8080-exec-80 url:/login.jsp ... url:/rest/cc/1.0/resource/colors username:someuser at java.lang.StringCoding.decodeUTF8_0([BIIZ)Ljava/lang/StringCoding$Result; (Unknown Source) at java.lang.StringCoding.decodeUTF8([BIIZ)Ljava/lang/StringCoding$Result; (Unknown Source) at java.lang.StringCoding.decode(Ljava/nio/charset/Charset;[BII)Ljava/lang/StringCoding$Result; (Unknown Source) at java.lang.String.<init>([BIILjava/nio/charset/Charset;)V (Unknown Source) at java.lang.String.<init>([BLjava/nio/charset/Charset;)V (Unknown Source) at org.apache.lucene.document.DocumentStoredFieldVisitor.stringField(Lorg/apache/lucene/index/FieldInfo;[B)V (DocumentStoredFieldVisitor.java:75) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsReader.readField(Lorg/apache/lucene/store/DataInput;Lorg/apache/lucene/index/StoredFieldVisitor;Lorg/apache/lucene/index/FieldInfo;I)V (CompressingStoredFieldsReader.java:217) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsReader.visitDocument(ILorg/apache/lucene/index/StoredFieldVisitor;)V (CompressingStoredFieldsReader.java:590) at org.apache.lucene.index.CodecReader.document(ILorg/apache/lucene/index/StoredFieldVisitor;)V (CodecReader.java:84) at org.apache.lucene.index.BaseCompositeReader.document(ILorg/apache/lucene/index/StoredFieldVisitor;)V (BaseCompositeReader.java:118) at org.apache.lucene.index.IndexReader.document(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (IndexReader.java:373) at org.apache.lucene.search.IndexSearcher.doc(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (IndexSearcher.java:332) at com.atlassian.jira.index.stats.IndexSearcherWithStats.doc(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (IndexSearcherWithStats.java:48) at com.atlassian.jira.index.DelegateSearcher.doc(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (DelegateSearcher.java:108) at com.atlassian.jira.index.DelegateSearcher.doc(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (DelegateSearcher.java:108) at com.atlassian.jira.index.UnmanagedIndexSearcher.doc(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (UnmanagedIndexSearcher.java:9) at com.atlassian.jira.index.DelegateSearcher.doc(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (DelegateSearcher.java:108) at com.atlassian.jira.index.ManagedIndexSearcher.doc(ILjava/util/Set;)Lorg/apache/lucene/document/Document; (ManagedIndexSearcher.java:15) at com.atlassian.jira.issue.search.providers.LuceneSearchProvider.getDocument(Ljava/util/Set;Lcom/atlassian/jira/index/ManagedIndexSearcher;Ljava/lang/Integer;)Lcom/atlassian/jira/issue/search/DocumentWithId; (LuceneSearchProvider.java:416) at com.atlassian.jira.issue.search.providers.LuceneSearchProvider.lambda$search$0(Ljava/util/Set;Lcom/atlassian/jira/index/ManagedIndexSearcher;Ljava/lang/Integer;)Lcom/atlassian/jira/issue/search/DocumentWithId; (LuceneSearchProvider.java:388) at com.atlassian.jira.issue.search.providers.LuceneSearchProvider$$Lambda$4714.apply(Ljava/lang/Object;)Ljava/lang/Object; (Unknown Source) ... at com.sun.proxy.$Proxy2556.search(Lcom/atlassian/jira/user/ApplicationUser;Lcom/atlassian/query/Query;Lcom/atlassian/jira/web/bean/PagerFilter;)Lcom/atlassian/jira/issue/search/SearchResults; (Unknown Source) at com.ascendintegrated.colorcards.service.AdminServiceImpl.getSearchForIssues(Ljava/lang/String;Ljava/lang/String;)Ljava/util/Collection; (AdminServiceImpl.java:356) at com.ascendintegrated.colorcards.service.AdminServiceImpl.getColorMapping(Ljava/lang/String;Ljava/lang/String;)Ljava/util/Map; (AdminServiceImpl.java:150) at com.ascendintegrated.colorcards.rest.Resource.getColors(Ljavax/servlet/http/HttpServletRequest;)Ljavax/ws/rs/core/Response; (Resource.java:57) ...

If you were able to make the same observations while analyzing the heap dump generated with the OOM error, then this KB is relevant and you can refer to the Cause and Solution sections.

Cause

The Jira outages are caused by the 3rd party add-on Color Cards for Jira. As mentioned in its Marketplace listing, this add-on can be used to configure card colours on Scrum and Kanban boards, based on issue types, JQL queries, etc... When a user tries to configure the card colours for a Jira SCRUM (or Kanban) board, the add-on starts to use an excessive amount of heap memory, and eventually the Garbage Collector is unable to clear it, and the Jira application becomes unavailable. Please note that outage might happen more or less quickly, depending on how much heap memory is allocated to the Jira application.

It is important to note that the Jira application comes with a native card colour setting called Card Colours, while the add-on card colour feature is called Color Cards. The problematic setting in this case is the Color Cards setting:

(Auto-migrated image: description temporarily unavailable)

Solution

Temporary Solution

The temporary solution is to disable the 3rd party add-on Color Cards for Jira, to prevent this add-on from using an excessive amount of Java Heap Memory.

Long Term Solution

For a long term solution, please reach to the add-on vendor support team using their support portal for further assistance, since 3rd party add-ons fall outside of Atlassian Support Scope, as we do not own their code nor have the expertise to troubleshoot them.

Updated on March 11, 2025
Platform
Data Center only
Product
Jira Software Data Center
On this pageSummaryDiagnosisCauseSolution

Still need help?

The Atlassian Community is here for you.
Ask the Community