Tomcat hangs calling TimeZone

Question

I have this issue that is bringing down production. In an AWS/Ubuntu/Tomcat stack, the CPU's running Tomcat 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.)

"TP-Processor6" daemon prio=10 tid=0x0000000041ec2800 nid=0x41c4 runnable [0x00007f70194b5000]
  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:1109)
    at java.util.GregorianCalendar.<init>(GregorianCalendar.java:576)
    at java.util.Calendar.createCalendar(Calendar.java:1011)
    at java.util.Calendar.getInstance(Calendar.java:948)
    at com.xxx.core.util.DateUtil.modifyDate(DateUtil.java:385)
    at com.xxx.core.util.DateUtil.getDayDate(DateUtil.java:563)
    at com.xxx.core.util.DateUtil.getDayDate(DateUtil.java:573)
    at com.xxx.core.util.DateUtil.getDayDate(DateUtil.java:569)
    at com.xxx.core.util.DateUtil.splitByDays(DateUtil.java:496)
    at com.xxx.core.util.DateUtil.splitDateIntervalByIntervals(DateUtil.java:474)
    at com.xxx.core.util.DateUtil.splitDateIntervalByIntervals(DateUtil.java:436)

It seems some OS setting issue, did you try on other machine? — kosa, Aug 31 '12 at 12:53
Are you providing a TimeZone, or is it getting the default one? — Jon Skeet, Aug 31 '12 at 12:55
ubuntu@ip-10-2-118-175:~$ java -version java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) — Stephen Chambers, Aug 31 '12 at 13:04
The code that is calling the Calendar.getInstance does so like this: Calendar calendar = Calendar.getInstance(); calendar.setTime(date); calendar.setTimeZone(TimeZone.getDefault()); — Stephen Chambers, Aug 31 '12 at 13:06
No stack overflow, It just hangs. I have seen some random posts where it produces a stack overflow, but not in our case. — Stephen Chambers, Aug 31 '12 at 13:07
Also, haven't seen it on any other machine, but it is happening on both machines in this production cluster. — Stephen Chambers, Aug 31 '12 at 13:08
As far as a stack overflow, it would probably be happening if we gave it long enough. We have a box with a lot of CPU. — Stephen Chambers, Aug 31 '12 at 14:49
This is happening for me on Weblogic too. Causing Weblogic **Stuck Threads**. — Sabir Khan, Apr 27 '17 at 04:22

score 1 · Answer 1 · answered Sep 01 '12 at 10:32

1

Wrap some better logging around things to figure out what is going on here.

Make sure your instance is specifying proper encoding and Locale -- system, tomcat container, application. Settle on GMT as a standard and try:

Calendar.getInstance ("GMT-0", Locale.US); // verify inputs

If you are getting an instance of a Calendar, why are you re-setting the date explicitly? Why not just create a new Calendar? You would then be instantiating a new Calendar:

Calendar cal = new Calendar (TimeZone zone, Locale aLocale); // new 
cal.setTimeZone("GMT-0"); 
cal.setTimeInMillis(System.currentTimeMillis ());

Calendar and Date objects are relatively malleable in Java, so you can change up how they function. I am guessing that there may be something not set right in the environment variables or container, such as Local or encoding that is conflicting with what is being attempted with the Calendar instance. Try specifying everything explicitly.

That's my best intuition.

answered Sep 01 '12 at 10:32

ingyhere

11,818
3
38
52

From posts elsewhere, I added joda-time (Which I like a lot, btw) but that lead me to discover that the problem was not what I thought it was. Although I literally looked at 12-15 different thread dumps and they all showed the same thing -- the method above -- it was actually spinning in a tight loop and the thread was always accidently in the same place. The length of execution of that one method, the getTransitionIndex() call, must be so long in relation to all the others, that every time I looked at what the thread was doing, it was always in the same place. D'oh! – Stephen Chambers Sep 04 '12 at 14:04
Joda Time is great, just be aware of its limitations. I understand that Joda Time is limited to millisecond precision whereas some DBs like microsecond or better precision. Also, I don't think it handles leap seconds well, if I recall. http://stackoverflow.com/questions/375544/are-there-any-cons-to-using-jodatime – ingyhere Sep 04 '12 at 16:51
Oh, and I'm glad you found the root source of the issue. I hope the logging helped. :) – ingyhere Sep 04 '12 at 16:51

Tomcat hangs calling TimeZone

1 Answers1