Timeouts in the JIRA Issues Macro or Highlighting Plugin

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.


When trying to use the JIRA Issues Macro or the Highlighting plugin (or any other form of JIRA integration), you may find that they timeout and throw various errors such as:

-	Data cannot be retrieved due to an unexpected error
-	Received the following HTTP error code from the server:504
-	java.net.SocketTimeoutException: Read timed out

This KB article is going to explore how to diagnose these problems as well as provide some of the known causes.


Set the following packages to DEBUG (for more information on how to do this, see Configuring Logging):

  • com.atlassian.confluence.extra.jira
  • com.atlassian.confluence.plugins.JIRA
  • com.atlassian.confluence.plugins.createjiracontent

Having done so, replicate the problem. You should see something like the following in your logs:

java.net.SocketTimeoutException: Read timed out
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:152)
	at java.net.SocketInputStream.read(SocketInputStream.java:122)
	at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
	at sun.security.ssl.InputRecord.read(InputRecord.java:480)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
	at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
	at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
	at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
	at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
	at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
	at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
	at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
	at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
	at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
	at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
	at com.atlassian.sal.core.net.HttpClientRequest.executeMethod(HttpClientRequest.java:590)
	at com.atlassian.sal.core.net.HttpClientRequest.executeMethod(HttpClientRequest.java:546)
	at com.atlassian.sal.core.net.HttpClientRequest.executeAndReturn(HttpClientRequest.java:350)
	at com.atlassian.plugins.rest.module.jersey.JerseyRequest.executeAndReturn(JerseyRequest.java:161)
	at com.atlassian.applinks.core.auth.ApplicationLinkRequestAdaptor.execute(ApplicationLinkRequestAdaptor.java:84)
	at com.atlassian.applinks.core.auth.trusted.TrustedRequest.execute(TrustedRequest.java:39)
	at com.atlassian.confluence.extra.jira.DefaultJiraIssuesManager.retrieveXML(DefaultJiraIssuesManager.java:90)
	at com.atlassian.confluence.extra.jira.CacheJiraIssuesManager.retrieveXML(CacheJiraIssuesManager.java:41)
	at com.atlassian.confluence.extra.jira.DefaultJiraIssuesManager.retrieveXMLAsChannel(DefaultJiraIssuesManager.java:172)
	at com.atlassian.confluence.extra.jira.services.DefaultJiraIssueBatchService.retrieveChannel(DefaultJiraIssueBatchService.java:132)
	at com.atlassian.confluence.extra.jira.services.DefaultJiraIssueBatchService.getBatchResults(DefaultJiraIssueBatchService.java:79)
	at com.atlassian.confluence.extra.jira.StreamableJiraIssuesMacro.trySingleIssuesBatching(StreamableJiraIssuesMacro.java:190)
	at com.atlassian.confluence.extra.jira.StreamableJiraIssuesMacro.executeToStream(StreamableJiraIssuesMacro.java:104)
	at com.atlassian.confluence.content.render.xhtml.view.macro.ViewMacroMarshaller.marshalInternal(ViewMacroMarshaller.java:139)
	at com.atlassian.confluence.content.render.xhtml.view.macro.ViewMacroMarshaller.marshal(ViewMacroMarshaller.java:88)

To break this stack trace down, Confluence is trying to render the JIRA Issues macro (ViewMacroMarshaller.marshal()), attempting to retrieve XML data regarding the issue(s) from JIRA (DefaultJiraIssuesManager.retrieveXML()), which then uses the applink to communicate with JIRA (TrustedRequest.execute()), and is timing out when reading the data JIRA is providing (SocketInputStream.read()). If you have an undescriptive error message in the UI, this extra logging in invaluable for tracking down the problem.

Another useful Diagnostic step to take is to use your browser console to monitor the timing of some of the requests generated (Note: If you've contacted Support, it's very useful to create a HAR file for them, which contains this information):

Note that in this example the call to proxy?_=1428473037177 returned a 504 error, indicating a timeout. You can click through into the request itself to get more information about this, including the full URL that is being hit. In this case, my full URL is: http://localhost:10564/confluence/plugins/servlet/applinks/proxy?_=1428473037177. This shows that one of the requests over the applink is very slow, but doesn't tell us what is being requested over the applink. Luckily, if you click on the 'Response' tab, you should get some more information about what was returned by this particular request. In my case:

HTTP Status 504 - There was an error proxying your request to http://example.atlassian.com:8090/jira/rest/api/2/field?_=1428473330670 because of java.net.SocketTimeoutException: Read timed out

This shows the call that the application link is actually making (Note: calls over application links go through a built in proxy to get around potential network restrictions). In this case, we're looking for the set of fields available in JIRA, which is required by the JIRA Issues Macro. Here's a sample of the JSON data about these fields that was returned when I hit the URL (http://example.atlassian.com:8090/jira/rest/api/2/field?_=1428473330670) from the error message above:

Click here to expand...


      "name":"Last Viewed",

In this case, it could be that there are many custom fields in your instance and it's taking a very long time for Confluence to download all this information, which surpasses the built-in timeouts and causes the call to JIRA to fail.


Before attributing the problem to timeouts, we should check the Application Link itself. To do so, use the Application Links Troubleshooting Guide to confirm that the Application Link is healthy.

Having ruled this out, we can look at timeouts. In pre-5.8 instances, there are a few different timeouts that will prevent Confluence from getting data from JIRA. These are explored below.

Resolution 1

In order to resolve this issue, a few workarounds will need to be used depending on what version of Confluence you're on.

In modern versions of Confluence (post 6.0), adjusting the JVM parameters and the Socket Timeout should suffice in this workaround. See Configuring System Properties for more detailed step-by-step information on how to do this.

The following three lines can be appended to extend the JIRA integration socket timeout to 60 seconds:

CATALINA_OPTS="-Datlassian.http.socket.timeout=60000 ${CATALINA_OPTS}"
CATALINA_OPTS="-Dplugin.jira-integration.remote.timeout.connection=60000 ${CATALINA_OPTS}"
CATALINA_OPTS="-Dplugin.jira-integration.remote.timeout.socket=60000 ${CATALINA_OPTS}"

Additionally, you may need the system property that is described in: Jira Issues macros timeout in Confluence after 5 seconds:

CATALINA_OPTS="-Datlassian.http.connection.timeout=60000 ${CATALINA_OPTS}"

The socket and connection timeouts in General Configuration are ignored by the JIRA Issues macro and instead default to the following:


Setting the system properties listed in the resolution 1 section above resolves this. 

Resolution 2

If the plugins below fail to update their versions after installing, it's likely that the version in your instance is higher than what's listed below, and thus already includes the fix already. If in doubt, please reach out to Support.

  • Set the Socket Timeout in the admin menu as discussed above.
  • CONFSERVER-36316 - Getting issue details... STATUS  

     Please add the following to your system properties in bin/setenv.sh: CATALINA_OPTS="$CATALINA_OPTS -Dhttp.socket.timeout=YOUR_NEW_TIMEOUT_IN_MILLISECONDS". The socket timeout in General Configuration is ignored by the JIRA Issues macro and instead defaults to 10 seconds. This system property resolves this.

  • CONFSERVER-36870 - Getting issue details... STATUS / CONFSERVER-34233 - Getting issue details... STATUS

     Please install confluence-jira-content-1.8.4.jar via  file upload. The editor has a 12 second timeout which applies to all AJAX queries, including those used by the JIRA Issues macro. The fixes to these plugins allow this timeout to be bypassed.

  • CONFSERVER-36335 - Getting issue details... STATUS

    Please install jira-integration-plugin-1.6.3.jar via file upload, then add the following to your system properties in bin/setenv.sh: CATALINA_OPTS="$CATALINA_OPTS -Dplugin.jira-integration.remote.timeout.socket=YOUR_TIMEOUT_IN_MILLISECONDS". This resolves a specific problem requesting project information from JIRA which has its own timeout (that defaults to 10 seconds).

If you're still having problems at this point, please contact Support.

DescriptionWhen trying to use the JIRA Issues Macro or the Highlighting plugin (or any other form of JIRA integration), you may find that they timeout and throw various errors.
Last modified on Jan 14, 2020

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.