Its been quite a long time since I blogged. Been thinking for a awhile that I should restart it. So here comes a tit-bit thanks to me recently dating, ahem I meant dealing with the ubiquitous SimpleDateFormat class in Java.
All of us would have invariably used this handy SimpleDateFormat class from the JDK to set up a proper date, ugh java.util.Date you minion, what else can you do with it? While developing webapps, since every request invariably gets its own thread, this class is pretty safe to indulge with.
My date with the SimpleDateFormat class that had always been a pleasant affair until then, suddenly became a trying relationship between us. I squarely blame it on my not understanding dates properly. Well at least its thread-unsafe nature was something I was not aware of.
So while burning the proverbial mid-night oil trying to crunch log files of the order of a couple of dozen GBs a day, I was spawning few tens of threads. As part of the processing, I was trying to convert a java.util.Date to JSON date format string. I was using a static formatter object for formatting and then all hell broke loose. Some of my dates were getting messed up while most were just fine.
My initial suspicion was around the library that I was using for that purpose. So used another JSON library and again ended up with the same messed up date thingy once in a while. That incorrect suspicion cost me half a day. It was only then that I wondered if the hitherto-assumed-to-be-benign SimpleDateFormat could be the culprit. Google promptly confirmed my suspicion that it was indeed thread-unsafe! Was wondering why some JDK classes did not support thread-safety by default.
Having identified the problem, the fix was quite simple. Either I could synchronize the static formatting method that I was using or I could make the formatter a member of the Runnable itself. I chose the latter as I did not want the formatting method to be a bottleneck in the heavy-duty processing that I was doing. Problem solved after wasting a day.
If you could use Java 8, yet another option was to use the DateTimeFormatter class, which is thread-safe.
Here is the code snippet that caused the trouble in a multi-threaded environment.
public static SimpleDateFormat sdf = new SimpleDateFormat("MMM dd HH:mm:ss z yyyy");
public static String formatDate(Date inputdate) {
String dt = sdf.format(inputdate);
return dt;
}
Here is a link on the same topic on SO where the problem is discussed.
Lesson #1 : when using a library in a multi-threaded environment DO NOT assume thread-safety!
Lesson #2 : RTFM instead of making assumptions
All of us would have invariably used this handy SimpleDateFormat class from the JDK to set up a proper date, ugh java.util.Date you minion, what else can you do with it? While developing webapps, since every request invariably gets its own thread, this class is pretty safe to indulge with.
My date with the SimpleDateFormat class that had always been a pleasant affair until then, suddenly became a trying relationship between us. I squarely blame it on my not understanding dates properly. Well at least its thread-unsafe nature was something I was not aware of.
So while burning the proverbial mid-night oil trying to crunch log files of the order of a couple of dozen GBs a day, I was spawning few tens of threads. As part of the processing, I was trying to convert a java.util.Date to JSON date format string. I was using a static formatter object for formatting and then all hell broke loose. Some of my dates were getting messed up while most were just fine.
My initial suspicion was around the library that I was using for that purpose. So used another JSON library and again ended up with the same messed up date thingy once in a while. That incorrect suspicion cost me half a day. It was only then that I wondered if the hitherto-assumed-to-be-benign SimpleDateFormat could be the culprit. Google promptly confirmed my suspicion that it was indeed thread-unsafe! Was wondering why some JDK classes did not support thread-safety by default.
Having identified the problem, the fix was quite simple. Either I could synchronize the static formatting method that I was using or I could make the formatter a member of the Runnable itself. I chose the latter as I did not want the formatting method to be a bottleneck in the heavy-duty processing that I was doing. Problem solved after wasting a day.
If you could use Java 8, yet another option was to use the DateTimeFormatter class, which is thread-safe.
Here is the code snippet that caused the trouble in a multi-threaded environment.
public static SimpleDateFormat sdf = new SimpleDateFormat("MMM dd HH:mm:ss z yyyy");
public static String formatDate(Date inputdate) {
String dt = sdf.format(inputdate);
return dt;
}
Here is a link on the same topic on SO where the problem is discussed.
Lesson #1 : when using a library in a multi-threaded environment DO NOT assume thread-safety!
Lesson #2 : RTFM instead of making assumptions
No comments:
Post a Comment