Calendar, DateFormat and multi threading

Another anecdote from the ongoing Java 1.4 to Java 5 transition... Last time it was an incarnation of "Favor composition over inheritance". This time I am writing about a multi-threading issue which can be equally subtle and difficult to pinpoint.

On the test systems we have set up we observed two strange types of exceptions at seemingly random times and in various different areas of the application. They looked similar to the following two patterns:

  • java.lang.ArrayIndexOutOfBoundsException: 432
        at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436)
        at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2024)
        at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1941)
        at java.util.Calendar.setTimeInMillis(Calendar.java:1066)
        at java.util.Calendar.setTime(Calendar.java:1032)
        ... (our classes)

  • java.lang.ClassCastException: java.util.SimpleTimeZone
 at java.util.Calendar.writeObject(Calendar.java:1643)
 at sun.reflect.GeneratedMethodAccessor500.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:795)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294)
 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
 at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
 at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
 ... (more of this)
 ... (our classes)

Those errors, especially the first one, would suddenly happen at a seemingly random place. Re-running the program with the same inputs on the same machine would sometimes complete normally and sometimes crash at a different place.

Searching for the sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436) line brought me to Java Bug #6231579 which describes exactly our problem. The bug has been closed and classified as "not a bug", because they say that Calendar was not designed to be thread-safe and that suchlike behavior can be expected when sharing an instance over several threads. This is exactly what we found in our product: In a utility class we used two static final java.util.Calendar instances that were shared among all threads using the utility. Interestingly Calendar's javadoc does not mention the unsafe nature of the Calendar class. Alright, thinking about it in retrospective sharing them was not such a good idea after all, because one could have guessed that there might be problems. So changing this piece of code was rather easy, once it had been found.

However SimpleDateFormat's documentation includes a hint about synchronization issues. This one is even more important, because there are probably many more people using some shared instances of those and get bitten. There is a series of bugs reported about this, one of them being Bug #4264153.

So maybe it is time to search your code for all static usages of the Calendar and various ...Format classes, before you start getting strange errors.

Comments

Javin said…
Thanks for your comment on my post SimpleDateFormat in Java is not Thread-Safe Use Carefully. I see you have covered it 5 years ago :) thanks for your find bugs contribution you mentioned, gonna try it.
Mon Mar 26, 02:05:00 PM GMT+2
Post a Comment

Popular posts from this blog

SAXParseException: -1:-1: Premature End Of File - Misleading error

Today I had to look at a piece of code a colleague had written, using my XPathAccessor class. She used it in a servlet which gets XML formatted requests. As those are generated by an external 3rd party tool we agreed on some XML schema definitions. Everything they send us needs to conform to its corresponding schema, each reply we send gets validated against a different set. In order to allow independent testing on either side, we provided a little test kit that allows testing our system without having to set up a servlet engine. Basically it just takes a file, reads it into a String and hands that to the handler. First it gets parsed without validation. This is necessary to find out which type of request we were send (the address is the same for all of them). After the root element is known, it will be read again, this time using the right schema to verify the request. Once that is done, some reply is put together and sent back to the client. So far, so good. When I looked at
Read more

Amiga 500 Restoration: A501 Memory Expansion

Image
The previous posts were mostly about cosmetics. This one is more technical, dealing with the repair and some preventative maintenance of the A501 memory expansion card. If you are curious to learn more about the retrobrighting of the computer’s case, don’t worry — I’ll get back to that at a later time. This is the third post in a series about restoring an Amiga 500 back to its former glory. Here are all of them so far. I’ll try to remember to update this in all related entry. 2017-12-24:  Amiga 500 Restoration 2018-01-05: Retrobrighting I 2018-02-05: A501 Memory Expansion 2018-02-05: Mouse and Mainboard Maintenance Amiga Memory — The Basics When the Amiga 500 was first introduced, it came with 512KB of memory. That was already double the amount the original Amiga 1000 had, but still not a whole lot. Especially when developers started to get familiar with the audio and video capabilities of the machine, RAM became a limiting factor in what you could do. Merely copying a single
Read more

Something to know about Toshiba external USB HDD

As I wrote before, luckily I bought an external hard disk and started backing up my data just in time. Well, although this may look like talking bad about good things, I still believe I should post this. The drive model I bought is a Toshiba PX1269E-G50, a 500GB external USB 2.0 model. On the box it says this: Optimized for digital video, photos and music storage. Fanless design for near-silent operation. Interface: high-speed USB 2.0. Interface transfer rate (max.): 480 Mbps. Rotational speed: 7200 rpm. Cache: 16 MB. PushButton Backup. Password security. System requirements: PC with minimum 233 MHz pentium or equivalent (Celeron, AMD, etc.), Windows 2000/XP, available USB 2.0 port. I read this before buying in the store. I did not care for whatever "PushButton Backup" is. I still don't. I did not care for Password security. I still don't. It says Windows 2000/XP, but after all it is a USB mass storage device. Not needing the nifty Windows backup or security tools
Read more