[
https://issues.apache.org/jira/browse/TAPESTRY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Sommerville updated TAPESTRY-1571:
--------------------------------------
Attachment: TAP-1571.patch
Patch that:
- adds a tryWithWrite method to ConcurrentBarrier
- changes CheckForUpdatesFilter to use tryWithWrite instead of withWrite
- add configution parameter for the try update timeout.
> CheckForUpdatesFilter can cause deadlock
> ----------------------------------------
>
> Key: TAPESTRY-1571
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1571
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Ben Sommerville
> Attachments: TAP-1571.patch
>
>
> CheckForUpdatesFilter will cause a deadlock in the following circumstances.
> 1) Initial request is received and processing starts (CheckForUpdatesFilter
> read lock obtained)
> 2) Request processing triggers another http request to the same application
> 3) Nested request is received
> 4) CheckForUpdatesFilter determines it is time to check for file updates
> 5) CheckForUpdatesFilter tries to obtain write lock
> 6) Deadlock: Nested request is blocked waiting for read lock held by parent
> request to be released.
> This is an unusual situation, generally I wouldn't try to to access a page
> via http whilst trying to process another request. However I ran across this
> problem whilst using a third party library (JasperReports) that referenced
> resources via http links.
> Although uncommon, I believe Tapestry should be able to handle this without
> deadlocking
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
