bug 14578: possible race condition in xalan-J2 initialisation

[Simon Kitching <si...@ecnetwork.co.nz>]

Hi all,

I raised the following issue a week ago, with a candidate patch.
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14578>.

Is there anyone interested in giving me some feedback on this?

I am currently using Xalan in a production environment, and am getting
intermittent hangs on startup. I have not raised a bug for this issue
because as the problem is intermittent it is very difficult to get info
on it, or to generate a testcase demonstrating the problem. However, due
to some strategically-placed logging, I do know that the hang
occurs inside method XPathAPI.eval. It also appears to be caused by some
kind of thread race condition (my application has multiple threads
performing xml-related operations simultaneously on completely separate
xml DOMs).

Because this is a real issue to me, I am therefore planning to do an
"audit" of all Xalan code which uses "static" member variables. Bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14578 was the first
issue I found.

However, before spending too much time on this, I would like to know
that someone on the dev list is willing to assess any bugs I raise for
this, and review/apply patches.

So, if I look for the bugs, and provide patches, does anyone here have
the time to review/apply them?

Regards,

Simon Kitching <si...@ecnetwork.co.nz>

Re: bug 14578: possible race condition in xalan-J2 initialisation

[Joseph Kesselman <ke...@us.ibm.com>]

>However, before spending too much time on this, I would like 
>to know that someone on the dev list is willing to assess any
>bugs I raise for this, and review/apply patches.

"Willing" and "has time to do so immediately" may be different questions, 
especially at this time of year.

(I'd be willing and am interested, but I've got both a crash project and 
vacation that *must* be taken before the end of the year, so I can't make 
any promises about when I could get to it. Someone else may be able to 
look at it sooner...)

______________________________________
Joe Kesselman  / IBM Research