[
https://issues.apache.org/jira/browse/TAPESTRY-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Kuhnert resolved TAPESTRY-1234.
-------------------------------------
Resolution: Fixed
Fix Version/s: 4.1.2
Assignee: Jesse Kuhnert
Added commons-pool implementation for RegexpMatcher utility class.
> ResourceMatcherImpl not thread safe on multi-CPU system
> -------------------------------------------------------
>
> Key: TAPESTRY-1234
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1234
> Project: Tapestry
> Issue Type: Bug
> Components: Core, Framework
> Affects Versions: 4.1.1
> Reporter: Greg Woolsey
> Assigned To: Jesse Kuhnert
> Priority: Blocker
> Fix For: 4.1.2
>
>
> Load testing on a multi-CPU system uncovered another thread safety issue.
> I'm not sure why, because I'm unclear on the call flow, but the RegexpMatcher
> instance held by ResourceMatcherImpl can be called by two threads at once.
> This leads to predictable ArrayIndexOutOfBounds errors down in the ORO
> Perl5Matcher class, because that class has instance state that is being
> accessed by both threads, similar to the SimpleDateFormat issue in
> TAPESTRY-1229.
> I turned it into a ThreadLocal, which worked, but I think that loses some of
> the pattern caching performance benefits. Not sure what the best solution is,
> but a ThreadLocal is guaranteed to be safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://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]
