-
Bug
-
Resolution: Fixed
-
Low
-
7.19.17, 7.19.18, 8.5.5
-
9
-
Severity 3 - Minor
-
2
-
Issue Summary
Confluence's create-content operation (clicking the "..." button next to the Create button at the top left) results in a create-dialog window that can take up to 20 minutes to fully render.
This is reproducible on Data Center: yes
Steps to Reproduce
On an affected version of Confluence, where network configuration may block loopback calls from the Confluence server to its own base URL, click the "..." button.
note: internally, a call is triggered to
/rest/create-dialog/1.0/space-blueprint/dialog/web-items
Expected Results
The create-dialog should display within a second, and clicking on the relevant document type (Blank page, Blog post, DACI decision etc.) should then open up the editor with the corresponding blueprint template content.
Actual Results
The create dialog hangs and takes up to 20 minutes to fully load and function.
Since Tomcat's StuckThreadDetectionValve is generally set to 60 seconds, catalina.out will log a long running create-dialog endpoint thread, stalled for multiple minutes at the following thread state:
java.lang.Throwable at java.base@11.0.20.1/java.net.PlainSocketImpl.socketConnect(Native Method) at java.base@11.0.20.1/java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.base@11.0.20.1/java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.base@11.0.20.1/java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.base@11.0.20.1/java.net.SocksSocketImpl.connect(Unknown Source) at java.base@11.0.20.1/java.net.Socket.connect(Unknown Source) at java.base@11.0.20.1/sun.security.ssl.SSLSocketImpl.connect(Unknown Source) at java.base@11.0.20.1/sun.security.ssl.BaseSSLSocketImpl.connect(Unknown Source) at java.base@11.0.20.1/sun.net.NetworkClient.doConnect(Unknown Source) at java.base@11.0.20.1/sun.net.www.http.HttpClient.openServer(Unknown Source) at java.base@11.0.20.1/sun.net.www.http.HttpClient.openServer(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.https.HttpsClient.<init>(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.https.HttpsClient.New(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.http.HttpURLConnection.followRedirect0(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.http.HttpURLConnection.followRedirect(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source) at java.base@11.0.20.1/java.net.URLConnection.getContentType(Unknown Source) at java.base@11.0.20.1/sun.net.www.protocol.https.HttpsURLConnectionImpl.getContentType(Unknown Source) at org.apache.tika.io.TikaInputStream.get(TikaInputStream.java:557) at org.apache.tika.Tika.detect(Tika.java:307) at com.atlassian.confluence.plugins.createcontent.impl.DefaultIconUrlProvider.isValidIcon(DefaultIconUrlProvider.java:70)
Eventually, the thread will complete (up to 20 minutes later), but the following pattern may also appear in the atlassian-confluence.log signifying a failed attempt at validating an icon URL:
YYYY-MM-DD HH:MM:SS,mmm WARN [http-nio-8090-exec-22] [plugins.createcontent.impl.DefaultIconUrlProvider] isValidIcon Couldn't verify icon at <ConfluenceBaseURL>/s/-celk4g/8804/pkry9k/17.19.6/_/download/resources/com.atlassian.confluence.plugins.confluence-software-project:sp-space-blueprint-item/icon -- referer: <ConfluenceBaseURL>/ | url: /rest/create-dialog/1.0/space-blueprint/dialog/web-items | traceId: <REDACTED> | userName: <REDACTED>
Workaround
Ensure that network related settings (such as /etc/hosts | /etc/resolv.conf | C:\Windows\System32\drivers\etc\hosts etc.), JVM outbound proxy settings, and OS network proxy settings do not prevent Confluence server from being able to contact itself via the base URL.
- follows
-
VULN-1184988 Failed to load
Form Name |
---|
A fix for this issue is available in Confluence Server and Data Center 8.5.6.
Upgrade now or check out the Release Notes to see what other issues are resolved.