Anil,
I committed a fix which I believe should address this issue. I noted
the commit changes in the JIRA issue, so grab a copy of the trunk and
take a look whenever you get a chance.
-- Allen
Anil Gangolli wrote:
OK. I've filed
http://opensource.atlassian.com/projects/roller/browse/ROL-1221
to track it.
--a.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 24, 2006 8:15 AM
Subject: Re: SimpleDateFromat usage in Roller 3.0
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.
