#655 RegularTimePeriond not thread safe

1.0.x
closed-fixed
General (896)
8
2006-10-13
2006-08-08
Colin Crist
No

RegularTimePeriod.java (1.6.2.1) has a static Calendar.

I have seem this cause problems if if data is placed
into two TimeSeries concurrently - Dates can get
created with incorrect values and other weirdness
caused by Calendar not being thread safe.

I have worked around the problem by changing the
Calendar to being a ThreadLocal (I guess
Calendar.getInstance returns a new Calendar each time...)

public static final ThreadLocal WORKING_CALENDAR_TL =
new ThreadLocal () ;

public static Calendar getWorkingCalendar()
{
if (WORKING_CALENDAR_TL.get() == null)
{

WORKING_CALENDAR_TL.set(Calendar.getInstance(DEFAULT_TIME_ZONE))
;
}

return \(Calendar\) WORKING\_CALENDAR\_TL.get\(\) ;

}

Access to the calendar in the rest of the class is now
via this getter. It works fine except you will leak
Calendars when threads terminate. A better solution may
be to place the Calendars in an LRUMap with some
reasonable fixed upper limit.

Regards, Colin.

Discussion

  • David Gilbert

    David Gilbert - 2006-08-16

    Logged In: YES
    user_id=112975

    Thanks for the report. The shared calendar was a very bad
    idea - I'm experimenting at the moment with eliminating the
    calendar, and caching the start and end millisecond values
    for each period. A method will allow recalculating these
    for a particular time zone / calendar. The cached values
    should speed up chart drawing significantly for charts with
    a lot of data.

     
  • David Gilbert

    David Gilbert - 2006-08-16
    • assigned_to: nobody --> mungady
     
  • Colin Crist

    Colin Crist - 2006-08-17

    Logged In: YES
    user_id=66833

    David,

    Your solution sounds better and it may even help an issue I
    have with timeseries data in JFreeChart. My charts contain
    timeseries of latencies throught a day at 1 second
    intervals, typically from 7am to 5pm which makes it 36K
    timeseries entries per chart - this can make repaint times
    quite uncomfortable. Anything you can do to improve this is
    very welcome.

    The latencies for your background are latencies between
    componenents in a flow of messages and we're using this to
    create reports and compare days and drill down to the flow
    to see how applications behave based on business events and
    between new releases of applications.

    FWIW, my client and I have bought a few copies of your
    manual, very useful it has been too.

    Regards and thanks,

    Colin.
    http://hermesjms.com

     
  • David Gilbert

    David Gilbert - 2006-08-18

    Logged In: YES
    user_id=112975

    I've closed two other bugs that I think are duplicates of
    this one: 1452432 and 1497411. (Note that I just closed
    them as duplicates, they're not fixed yet).

    I'm under a little pressure to get 1.0.2 released, so the
    fix for this bug might not make it in to 1.0.2. But in that
    case, you can expect 1.0.3 to follow within a month and
    include a fix for this problem.

     
  • David Gilbert

    David Gilbert - 2006-08-18
    • priority: 5 --> 8
     
  • David Gilbert

    David Gilbert - 2006-10-13

    Logged In: YES
    user_id=112975

    The static calendar was a bad idea. In CVS now, it is
    deprecated and no longer used. This should fix this
    particular problem. The fix will be included in the 1.0.3
    release.

     
  • David Gilbert

    David Gilbert - 2006-10-13
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks