gotcha. that makes sense. i think most of the DateUtil stuff was like
back in the 2.x code so i'm not sure that this is anything new, but you
are certainly correct that this is a bit of a problem.
it looks like we can fix a lot of this just by cleaning up the DateUtil
class alone and making sure that it is acting in a thread safe manner by
not sharing instances and synchronizing where needed.
want to create a Jira issue for this so we can track it?
-- Allen
Anil Gangolli wrote:
Allen:
I didn't list them individually because there are a bunch. Here are
some techniques I'd use to track them down.
A lot of them originate in DateUtil, where the format is defined as a
single instance. DateUtil.format() itself does synchronize, but callers
of DateUtil can get references to the formats back and apply them
themselves.
For example, look for callers of DateUtil.get8charDateFormat(); consider
them all suspect, at least worth a check. Most of these callers get the
reference to the format and go on to call format() without synchronizing.
Another thing to look for is member fields of type SimpleDateFormat that
are in objects that are potentially shared across threads, for example,
HibernateWeblogManagerImpl which has a "formatter" field originally
defined to point to DateUtil.get8charDateFormat(), but which gets shared
quite heavily.
In some cases these member fields are in objects like RollerRequest that
are generally instantiated once per thread so it seems safe at first,
but when you look closely, the member reference actually goes back to a
shared static instance in DateUtil, so you end up with multi-threaded
access to it.
I wanted to kind of put a heads up out so that we would be careful not
to continue to increase the number of these things. I will try to start
going through and helping to fix them. The bugs that they cause tend to
have very hard-to-reproduce mysterious behaviors.
--a.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, August 23, 2006 9:51 AM
Subject: Re: SimpleDateFromat usage in Roller 3.0
Anil,
can you list the places where this is happening? the overwhelming
majority of the work for 3.0 happened in the ui.rendering package and
a quick glance at the use of SimpleDateFormat in those classes looks
okay to me.
i agree that we should try and find places where we are not including
a locale in the use of SimpleDateFormat and fix that.
-- Allen
Anil Gangolli wrote:
I'm seeing a couple of things related to SimpleDateFormat usage in
the Roller 3.0 codebase:
(1) There are a number of places where SimpleDateFormat is used in
the Roller 3.0 codebase where the instance is shared but there is no
synchronization being done. These things are not MT-safe.
(2) Most construction of the formats use locales, but there are a
number of places where SimpleDateFormat is constructed without a
locale. Not sure if these are issues; I think some are, and some
aren't. --a.
