Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-94170

Confluence's create-content operation takes up to 20 minutes to completely render the Create dialog

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              d5dce7b13926 agawron
              5c3a8aca27ce Mohit Sharma
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: