iCalendar plugin can cause Tomcat threadpool starvation due to infinite timeout

XMLWordPrintable

    • 9.04
    • 1
    • Severity 2 - Major
    • 1

      Issue Summary

      getTimeZone() method is called during execution of endpoint /rest/ical/1.0/ical/search/jql/events.ics

      The vendor library then calls updateDefinition(), which can result in a HTTP call to update timezone definitions to the internet. The implementation of this is as such that Tomcat thread starvation can occur if the HTTP connection is very slow or gets stuck.

      This is a known challenge with ical4j and is well described here: https://github.com/ical4j/ical4j/issues/479

      Steps to Reproduce

      1. Trigger an event that causes ical4j to update the timezone definitions (it is not immediately clear how to do this)
      2. Have an very slow internet connection to www.tzurl.org

      Expected Results

      The timezone definition update fails after a timeout value, and the definitions shipped with the distribution are in effect

      Actual Results

      The thread gets stuck infinitely loading definitions:

      "https-openssl-nio-443-exec-39 url: /rest/ical/1.0/ical/search/jql/events.ics; user: whispy" #2181 daemon prio=5 os_prio=0 cpu=2250.00ms elapsed=250261.73s tid=0x000000006cef7000 nid=0x3bc4 runnable  [0x00000009eeb18000]
         java.lang.Thread.State: RUNNABLE
      	at java.net.SocketInputStream.socketRead0(java.base@11.0.13/Native Method)
      	at java.net.SocketInputStream.socketRead(java.base@11.0.13/Unknown Source)
      	at java.net.SocketInputStream.read(java.base@11.0.13/Unknown Source)
      	at java.net.SocketInputStream.read(java.base@11.0.13/Unknown Source)
      	at java.io.BufferedInputStream.fill(java.base@11.0.13/Unknown Source)
      	at java.io.BufferedInputStream.read1(java.base@11.0.13/Unknown Source)
      	at java.io.BufferedInputStream.read(java.base@11.0.13/Unknown Source)
      	- locked <0x00000003886ee678> (a java.io.BufferedInputStream)
      	at sun.net.www.http.HttpClient.parseHTTPHeader(java.base@11.0.13/Unknown Source)
      	at sun.net.www.http.HttpClient.parseHTTP(java.base@11.0.13/Unknown Source)
      	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(java.base@11.0.13/Unknown Source)
      	- locked <0x00000003886ee728> (a sun.net.www.protocol.http.HttpURLConnection)
      	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(java.base@11.0.13/Unknown Source)
      	- locked <0x00000003886ee728> (a sun.net.www.protocol.http.HttpURLConnection)
      	at net.fortuna.ical4j.model.TimeZoneUpdater.updateDefinition(TimeZoneUpdater.java:111)
      	at net.fortuna.ical4j.model.TimeZoneLoader.loadVTimeZone(TimeZoneLoader.java:86)
      	at net.fortuna.ical4j.model.TimeZoneRegistryImpl.getTimeZone(TimeZoneRegistryImpl.java:193)
      	- locked <0x00000003886d9300> (a java.util.concurrent.ConcurrentHashMap)
      	at com.atlassian.jira.extra.icalfeed.IcalendarResource.toIcalendar(IcalendarResource.java:340)
      	at com.atlassian.jira.extra.icalfeed.IcalendarResource.search(IcalendarResource.java:318)
      	at com.atlassian.jira.extra.icalfeed.IcalendarResource.getIcalendarByJql(IcalendarResource.java:275)  

       

      Other threads requiring the same getTimeZone() are blocked, and thus, will eventually build up and completely starve the Tomcat thread pool as additional requests for ics data build up:

       

      "https-openssl-nio-443-exec-1 url: /rest/ical/1.0/ical/search/jql/events.ics; user: whispy" #2140 daemon prio=5 os_prio=0 cpu=1235343.75ms elapsed=250261.77s tid=0x000000007ddba000 nid=0x36d0 waiting for monitor entry  [0x00000009ea089000]
         java.lang.Thread.State: BLOCKED (on object monitor)
      	at net.fortuna.ical4j.model.TimeZoneRegistryImpl.getTimeZone(TimeZoneRegistryImpl.java:190)
      	- waiting to lock <0x00000003886d9300> (a java.util.concurrent.ConcurrentHashMap)
      	at com.atlassian.jira.extra.icalfeed.IcalendarResource.toIcalendar(IcalendarResource.java:340)
      	at com.atlassian.jira.extra.icalfeed.IcalendarResource.search(IcalendarResource.java:318)
      	at com.atlassian.jira.extra.icalfeed.IcalendarResource.getIcalendarByJql(IcalendarResource.java:275)

      Workaround

      Restart the Jira service to restore normal operations.

      To prevent the problem reoccuring, JVM startup parameters and be adjusted, followed by a service restart.

      Either disable web timezone update completely:

      -Dnet.fortuna.ical4j.timezone.update.enabled=false
      

      Or, apply sane timeout values:

      -Dnet.fortuna.ical4j.timezone.update.timeout.read=30000
      -Dnet.fortuna.ical4j.timezone.update.timeout.connect=5000
      

       

            Assignee:
            Unassigned
            Reporter:
            Alex [Atlassian,PSE]
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: