ORO Perl5Matcher and Perl5Compiler are used in thread-unsafe manner
-------------------------------------------------------------------
Key: TAPESTRY-778
URL: http://issues.apache.org/jira/browse/TAPESTRY-778
Project: Tapestry
Type: Bug
Components: Framework
Versions: 4.0
Environment: Windows XP SP2, HotSpot JVM, JBoss 4.0.3
Reporter: Jeff Lubetkin
Priority: Critical
>From the Jakarta ORO Javadocs
>(http://jakarta.apache.org/oro/api/org/apache/oro/text/regex/Perl5Matcher.html):
"Perl5Compiler and Perl5Matcher are designed with the intent that you use a
separate instance of each per thread to avoid the overhead of both
synchronization and concurrent access (e.g., a match that takes a long time in
one thread will block the progress of another thread with a shorter match). If
you want to use a single instance of each in a concurrent program, you must
appropriately protect access to the instances with critical sections. If you
want to share Perl5Pattern instances between concurrently executing instances
of Perl5Matcher, you must compile the patterns with
Perl5Compiler.READ_ONLY_MASK."
Tapestry 4.0 violates this in two ways:
1) The class org.apache.tapestry.form.validator.ValidatorFactoryImpl is a
singleton, and uses a single org.apache.tapestry.util.RegexpMatcher for
matching "validators" binding strings. This in turn uses a single
Perl5Matcher. If multiple pages/components that use a "validators" binding are
instantiated simultaneously, a race condition exception can occur.
2) A singleton RegexpMatcher is potentially using the same cached compiled
pattern on multiple threads simultaneously, yet they are not compiled with
Perl5Compiler.READ_ONLY_MASK.
My project has run into #1 by running a load test (using Grinder) rendering a
single page over and over that contains a component with a "validators"
binding. Frequently, StringIndexOutOfBoundsException would be thrown from
inside the Perl5Matcher stack. I was able to stop this by putting a
synchronized block around the call to _matcher.getMatches in
ValidatorFactoryImpl.constructValidatorList, but this is not likely the best
solution, and requires a patch as it doesn't seem straightforward to override
ValidatorFactoryImpl in the hivemodule files.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
