[
https://issues.apache.org/jira/browse/TAPESTRY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505427
]
Ben Sommerville commented on TAPESTRY-1571:
-------------------------------------------
The loopback is not caused by clearing the cache. The problem shows up when a
cache clear is triggered by a loopback request.
Specifically in my case I am using Jasper Reports to produce some PDF reports
for the user. The app has a page where the user can request a report to be run
& then see the PDF result. So the creation of the report happens completely
within the context of that page request.
The reports that are being produced include images and other sub reports.
These other resources are external to the main report definition. The main
report includes a reference which is ultimately resolved to an URL (its more
complicated in practice but that is the net effect).
When Jasper is processing the main report it hits one of the image and/or
sub-report references & fetches that image/subreport from the specified URL
This request is done by the Jasper engine within the context of the initial
page request.
It is these requests (by Jasper) for report resources which trigger a deadlock.
This occurs when one of those requests is received by the app & the
CheckForUpdatesFilter determines it is time to carry out an update check.
The filter tries to obtain its write lock (line 85) but it can't because the
initial page request holds a read lock. The initial request never relinquishes
the read lock because it waiting for the resource request to return. (That is
probably not strictly true... I expect something would timeout eventually).
Ideally Jasper would have a more pluggable mechanism for resolving references
to external resources. However it has no extension points at all so I am left
with supplying an URL back to the application.
I hope that all makes sense.
> 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]
