Problem

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 Gateway Timeout 
-	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.

Diagnosis

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 Gateway Timeout 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:

...
   {
      "id":"lastViewed",
      "name":"Last Viewed",
      "custom":false,
      "orderable":false,
      "navigable":true,
      "searchable":false,
      "clauseNames":[
         "lastViewed"
      ],
      "schema":{
         "type":"datetime",
         "system":"lastViewed"
      }
   },
   {
      "id":"comment",
      "name":"Comment",
      "custom":false,
      "orderable":true,
      "navigable":false,
      "searchable":true,
      "clauseNames":[
         "comment"
      ],
      "schema":{
         "type":"array",
         "items":"comment",
         "system":"comment"
      }
   },
   {
      "id":"watches",
      "name":"Watchers",
      "custom":false,
      "orderable":false,
      "navigable":true,
      "searchable":false,
      "clauseNames":[
         "watchers"
      ],
      "schema":{
         "type":"array",
         "items":"watches",
         "system":"watches"
      }
   },
...
]

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.

Cause

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}"

    DEFAULT_SOCKET_TIMEOUT_MS = 15000;
    DEFAULT_CONNECT_TIMEOUT_MS = 5000;

Resolution 2

• 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).