CDV ❯ Calendar should have honor transient set to true, else it results into NullPointerException.
-
Bug
-
Status: Resolved
-
2 Major
-
Resolution: Won't Fix
-
Byte Code Transform
-
-
interfaces
-
Reporter: ag_rocks
-
September 11, 2009
-
0
-
Watchers: 2
-
February 12, 2014
-
February 12, 2014
Attachments
Description
The class StandardDSOClientConfigHelperImpl instruments GregorianCalender and honours transients. But honour transient is false is not done for the abstract Calendar class.
Scenario :
A GregorianCalendar Object is created and shared. As we do not honour transient for Calener class, the transient field areAllFieldsSet is set to true and is available on other nodes to access, but not the transient fields in GregorianCalender.java . Now when this GregorianCalnder object is accessed on the some other node and materialized (hydrated), areAllFieldsSet remains true whereas the transient fields of GregorianCalender are all null.
An access to GregorianCalender.add(int, int), results in a call to setTimeInMillis(long) which uses areAllFieldsSet to recompute the transient field (mostly) of GregorianCalender object. But because areAllFieldsSet is true all the time, this does not sets field like calsys and hence a NULL Pointer Exception.
I have attached a sample code to reproduce this problem.
Steps to reproduce.
- Use tc-config1.xml.
- Run CalendarTest.java with Terracotta.
- Run it again and it throws a Null Pointer Exception
Exception in thread “main” java.lang.NullPointerException at java.util.GregorianCalendar.getCurrentFixedDate(GregorianCalendar.java:2859) at java.util.GregorianCalendar.add(GregorianCalendar.java:981) at com.terracottatest.CalendarTest.main(CalendarTest.java:18)
Comments
A G 2009-09-11
A G 2009-09-11
The one which solves the issue temporarily.
Alex Miller 2009-09-11
I linked to CDV-606 which is the best collection of dev work on this (there are several jiras out there related to this). At the moment, there is no one good solution and our product mgmt effectively owns deciding what to do with it.
Adding locking to GregorianCalendar is probably a bad thing because it can have large performance impacts to do that. It may be better to a) not share calendars or b) provide sufficient locking in your app above the calendar level and then add the calendar classes to your additional boot jar classes in your tc-config.
Hung Huynh 2014-02-12
DSO is discontinued
To solve this issue a possible solution could be a tc-config2.xml as attached. We need to rebuild the boot jar with this tc-config because it needs to Instrument the Calender class which is already their in the boot jar.
Basically added honor transient for Calender.java.
The question here is, Is it a right way to do this?. Could honour transient behavior of Calender added inside the terracotta code (In StandardDSOClientConfigHelperImpl), because without this, its always a problem to perform operations on GregorianCalendar Object.
Calender Object is not a thread safe datastructure. We could possibly get rid of the UnLockSharedObjectExcpetions, by specifying auto-locks. But this could lead to a lot of lock hoping across the cluster even though we have read (they mutate the calender object). Will this be a problem ? If yes can we use somthing else close to GregorianCalendar, which is performant in a multi-threaded environment.