Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8162676

File timezone (tzdata16c). with last change for Chile's time, causes deadlock with JDK 1.6

XMLWordPrintable

      FULL PRODUCT VERSION :
      java version "1.6.0_27"
      Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
      Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)


      ADDITIONAL OS VERSION INFORMATION :
      Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux


      EXTRA RELEVANT SYSTEM CONFIGURATION :
      Amazon Web Service
      TimeZone S.O.: America / Santiago
      JBossAS [6.0.0.Final "Neo"]
      Ehcache 2.4.0

      A DESCRIPTION OF THE PROBLEM :
      Update the JDK's timezone configuration with the tzadata16c from IANA's site, for apply the change "Chile reverts from permanent to seasonal DST." briging to application server not accepted anymore request, the system is like if it's bringing down, but the proccess running anyway.
      The probblem occurrs only with the software uses date near from the change to summer schdule for Chile (e.g. 13th August)

      ACTUAL -
      The system use the CPU's running are jumping to 100% and when I get a thread dump, this one piece of code is constantly blocked at exactly the same place. (All the others are locked and waiting.)


      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      The jstacks result of this deadlock starts with:

      "http-cocha-jboss6%2F10.0.2.68-8080-4" daemon prio=10 tid=0x0000000042a9e800 nid=0x4888 runnable [0x00007fe87bae8000]
         java.lang.Thread.State: RUNNABLE
      at sun.util.calendar.ZoneInfo.getTransitionIndex(ZoneInfo.java:322)
      at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:248)
      at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:225)
      at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2024)
      at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1996)
      at java.util.Calendar.setTimeInMillis(Calendar.java:1110)
      at java.util.GregorianCalendar.<init>(GregorianCalendar.java:576)
      at java.util.Calendar.createCalendar(Calendar.java:1012)
      at java.util.Calendar.getInstance(Calendar.java:949)
      at es.xxx.TimeUtils.initCalendar(TimeUtils.java:219)

      Then the're more logs like:


      "HDScanner" prio=10 tid=0x00007fe875e07800 nid=0x4880 waiting on condition [0x00007fe87bc74000]
         java.lang.Thread.State: TIMED_WAITING (parking)
      at sun.misc.Unsafe.park(Native Method)
      - parking to wait for <0x00000006c33059d8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
      at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
      at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)
      at java.util.concurrent.DelayQueue.take(DelayQueue.java:164)
      at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)
      at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)
      at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
      at java.lang.Thread.run(Thread.java:662)

      "xxx.data" daemon prio=10 tid=0x00007fe875dfe800 nid=0x487a waiting on condition [0x00007fe87bcb5000]
         java.lang.Thread.State: TIMED_WAITING (parking)
      at sun.misc.Unsafe.park(Native Method)
      - parking to wait for <0x00000006d12cd0c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
      at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
      at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)
      at java.util.concurrent.DelayQueue.take(DelayQueue.java:164)
      at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)
      at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)
      at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
      at java.lang.Thread.run(Thread.java:662)

      "Replication Thread" daemon prio=10 tid=0x00007fe876006000 nid=0x4879 waiting on condition [0x00007fe87bcf6000]
         java.lang.Thread.State: TIMED_WAITING (sleeping)
      at java.lang.Thread.sleep(Native Method)
      at net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator.replicationThreadMain(RMIAsynchronousCacheReplicator.java:108)
      at net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator.access$100(RMIAsynchronousCacheReplicator.java:56)
      at net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator$ReplicationThread.run(RMIAsynchronousCacheReplicator.java:376)


      REPRODUCIBILITY :
      This bug can be reproduced always.

      CUSTOMER SUBMITTED WORKAROUND :
      with anotherr prior timezone of Iana (e.g. tzdata2016b) the system runs OK always. The latest timezone data all produces the same resulta.

            psonal Pallavi Sonal (Inactive)
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: