Uploaded image for project: 'Confluence Cloud'
  1. Confluence Cloud
  2. CONFCLOUD-40977

Ship Tomcat's long running (stuck) thread logging by default

XMLWordPrintable

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for Confluence Cloud. Using Confluence Server? See the corresponding suggestion.

      Adding this parameter to the server.xml will log stuck threads in the catalina.out:

      <Valve className="org.apache.catalina.valves.StuckThreadDetectionValve" threshold="60" />

      This will log any request thread (eg http thread) that has been processing for more than 60 seconds. This will not log background threads, eg scheduled jobs or any long running operation that processes in the background, like import/export, reindex etc.
      If you are expecting to see something in these logs that you do not, that does not mean it is not running for more than 60s. It likely just means it is not running in a request thread. Thread dumps over time are still the best way to diagnose long running threads.

            [CONFCLOUD-40977] Ship Tomcat's long running (stuck) thread logging by default

            Mona Sood added a comment -

            I have faced same warning in Confluence 6.6.6 v. Is there any resolution or workaround to avoid such issues?

            Mona Sood added a comment - I have faced same warning in Confluence 6.6.6 v. Is there any resolution or workaround to avoid such issues?

            Heshan Manamperi added a comment -

            Good feature! But How can I fix Tomcat's long running (stuck) threads?

            Heshan Manamperi added a comment - Good feature! But How can I fix Tomcat's long running (stuck) threads?

            jonah (Inactive) added a comment -

            QR complete

            jonah (Inactive) added a comment - QR complete

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - - edited

            From the docs we can also add an interruptThreadThreshold:

            Minimum duration in seconds after which a stuck thread should be interrupted to attempt to "free" it.
            Note that there's no guarantee that the thread will get unstuck. This usually works well for threads stuck on I/O or locks, but is probably useless in case of infinite loops.

            This is disabled by default. We have decided against enabling the interrupt threshold because of the below concerns:

            1. Copy Space plugin can sometimes run for hours, but completes in the end. This is done on a request thread.
            2. Space exports use long running tasks so wouldn't be affected
            3. Anything that gets off the request thread with an executorService wouldn't be effected by a valve. This would be request threads only.
            4. We run the risk of data corruption if we interrupt threads while they are actually processing
            5. Our applications are not designed to expect interruptions so this could have unintended consequences.

            If customers find this setting useful, they can apply it themselves on a case by case basis. We would recommend keeping an eye on it however to ensure it's not having any unintended consequences.

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - - edited From the docs we can also add an interruptThreadThreshold: Minimum duration in seconds after which a stuck thread should be interrupted to attempt to "free" it. Note that there's no guarantee that the thread will get unstuck. This usually works well for threads stuck on I/O or locks, but is probably useless in case of infinite loops. This is disabled by default. We have decided against enabling the interrupt threshold because of the below concerns: Copy Space plugin can sometimes run for hours, but completes in the end. This is done on a request thread. Space exports use long running tasks so wouldn't be affected Anything that gets off the request thread with an executorService wouldn't be effected by a valve. This would be request threads only. We run the risk of data corruption if we interrupt threads while they are actually processing Our applications are not designed to expect interruptions so this could have unintended consequences. If customers find this setting useful, they can apply it themselves on a case by case basis. We would recommend keeping an eye on it however to ensure it's not having any unintended consequences.

              dunterwurzacher Denise Unterwurzacher [Atlassian] (Inactive)
              dunterwurzacher Denise Unterwurzacher [Atlassian] (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: