Issue Summary

When Confluence is integrated with Jira, the Confluence user can create Jira issues directly from Confluence as explained in the product documentation.

Loading the create issue form, either on viewing or editing a page, may be slow while Confluence tries to get the the avatar for all projects in the target Jira instance, sending a request for each project from the user's browser to Confluence and then to Jira.

If the Jira instance has just a few projects, then it completes quickly, without the user noticing any delay.

If Confluence is connected to a large Jira instance, with thousands of projects, then it may take some seconds (or even minutes) to release the UI so the user can continue the process to create the Jira Issue.
If the Jira instance has 3,000 projects, then 3,000 requests will be created from the browser to Confluence, no matter if the project is not appearing in the screen.

A better design approach would be one of the two options:

1. Use paginated requests from the select box.
   • This would decrease the number of requests to Jira to only those projects the user is viewing in the UI.
   • For example, select2 has this feature.
2. Don't load the project avatar on the form.

Since Confluence would be processing thousands of requests from an user (or multiple users, leaning on how much this functionality is used), depending how fast it can process or drop these requests, there will be a lot of requests queued on Tomcat or on the HTTP server (if using a reverse proxy).
This can give other users the feeling that Confluence is not working or is slow, since new requests will also be queued.

Steps to Reproduce

1. Install a vanilla instance of Jira.
   • Jira 8.5.3 was used to validate the issue.
2. Create 2,000 sample projects.
   • You may use the following shell script to create these projects.

     JIRA_BASE_URL=https://jira.company.com/jira
     ATLASSIAN_XSRF_TOKEN=<can be taken from the browser's cookie>
     JSESSIONID=<can be taken from the browser's cookie>
     
     for i in $(seq 1 2000); do
        PROJECT_KEY=TEST${i}
        
        curl ${JIRA_BASE_URL}'/rest/jira-importers-plugin/1.0/demo/create' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H 'X-Atlassian-Token: no-check' -H 'X-Requested-With: XMLHttpRequest' -H 'Origin: '${JIRA_BASE_URL}' ' -H 'Connection: keep-alive' -H 'Cookie: atlassian.xsrf.token='${ATLASSIAN_XSRF_TOKEN}'; JSESSIONID='${JSESSIONID}'; mywork.tab.tasks=false' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data-raw 'name='${PROJECT_KEY}'&key='${PROJECT_KEY}'&keyEdited=true&projectTemplateWebItemKey=software-demo-project-scrum&projectTemplateModuleKey=undefined'
        
        echo ...
     done
     

3. Install a vanilla instance of Confluence.
   • The issue was validated on Confluence versions 6.13.10, 7.2.1 and 7.4.0.
4. Create an application link between Confluence and Jira.
   • Although it doesn't change anything on the bug behavior, create the link using impersonation so you don't need to allow authentication between applications.
5. Create a sample Space in Confluence.
6. Access the home page of the sample Space.
7. Highlight a text on the page and click on the Create Jira Issue icon to open the form.
8. On the Create Task form click on the Select project box.

Expected Results

Confluence quickly loads the options in the select box.

Actual Results

There will be a delay to have the select box opened and the browser may freeze for some seconds while thousands of requests are created the sent to Confluence.

If browser's developer tools is opened during the process, monitoring the network requests will shows 2,000 (or more depending on the number of projects) requests.

The requests are similar to

<Confluence Base URL>/plugins/servlet/jira-integration/icons?serverId=<jira server ID>&iconType=project&size=xsmall&avatarId=10324&pid=<project ID>

If there's an access log enabled on front of Jira (either on a reverse proxy or on Tomcat), there will be lots of requests similar to the below:

127.0.0.1 - - [05/Jun/2020:10:52:40 -0300] "GET /jira/secure/projectavatar?pid=11702&avatarId=10324&xoauth_requestor_id=admin HTTP/1.1" 200 1575 "-" "Apache-HttpClient/4.5.5 (Java/1.8.0_241)" "-" rt=0.031 uct="0.002" uht="0.032" urt="0.032"

Some of these requests may fail depending on the load on Confluence or on Jira – if Confluence and Jira are capable of dealing with all the requests, then these errors won't occur.
The request may fail with an HTTP 500 status and with a JiraCommunicationException error.
Looking at the Confluence application logs we may find entries similar to the below:

2020-06-05 10:53:43,551 ERROR [http-nio2-61510-exec-9] [[Standalone].[localhost].[/c61510].[servlet-module-container-servlet]] log Servlet.service() for servlet [servlet-module-container-servlet] in context with path [/c61510] threw exception
com.atlassian.integration.jira.JiraCommunicationException: The server may be unreachable. Please ensure you are running JIRA 5.0 or higher.
	at com.atlassian.internal.integration.jira.DefaultJiraService.newCommunicationException(DefaultJiraService.java:1156)
	at com.atlassian.internal.integration.jira.DefaultJiraService.newCommunicationException(DefaultJiraService.java:1149)
	at com.atlassian.internal.integration.jira.DefaultJiraService.communicateWithJira(DefaultJiraService.java:803)
	at com.atlassian.internal.integration.jira.DefaultJiraService.streamIcon(DefaultJiraService.java:579)
	at com.atlassian.internal.integration.jira.web.JiraIconServlet.doGet(JiraIconServlet.java:25)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
(...)
	at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)

If another user tries to display a page from Confluence while it is still processing the requests for the projects' avatars, then this new request may take a long time to be processed, since it will be queued on the Tomcat or Reverse Proxy side.
Depending on the timeout configuration of the Reverse Proxy, this new request may not even reach the Confluence server.

The same occurs if the user tries to create the Jira issue using the Jira Issues Macro when editing a page.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available.