[
https://issues.apache.org/jira/browse/ABDERA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Fields updated ABDERA-294:
------------------------------
Description:
The hrefParams map is cleared and then subsequent requests not properly routed.
Our problem doesn't occur on load, but rather occurs sometime after when two
requests hit cleanMapCtx in the right timing to have one clear out the map as
the other is grabbing the entry set, resulting in the second thread doing a
clear but having nothing to put back in. Then all subsequent requests don't
get routed properly.
This is similar to https://issues.apache.org/jira/browse/ABDERA-95 and
https://issues.apache.org/jira/browse/ABDERA-276 but does not occur under load,
just with two threads.
In the comments for that issue, there's a mention of a fix by using the code
from an earlier version. I haven't tested the code mentioned from 0.4.0, but
from looking at it the hrefParams isn't being modified, so that would seem to
solve our problem as well. I'm attaching the diff for the fix that we used,
which was to return the new map instance with the cleaned keys instead of
altering and returning the hrefParams.
The problem we experienced was that the ATOM feed would intitally be working,
but then would start returning 404 errors. We found that this was caused by
the hrefParams property of the AtomCollectionAdapter being corrupted (cleared
out) by the cleanMapCtx method in RouteManager. This occured when mutliple
threads hit RouteManager.cleanMapCtx in close succession, such that the first
thread cleans the shared map as the second is trying to iterate over the
entries in the map. The second thread will then clear the map, but have
nothing to put back in it, resulting in the map being empty for all future
requests.
We ran into this fairly often in testing with a decent load, but the easiest
way to recreate this on demand is to debug remotely and manually step through
two threads so that they hit at the right time. I've included the steps I used
below.
Steps to re-create by remote debugging:
Set breakpoint in RouteManager.cleanMapCtx line 176
In thread 1, step through to after the map has been cleared (line 181)
In thread 2, step through to line 180. This thread will now have an empty map,
since it got the entrySet after the first map was cleared, but before the putAll
Play thread 1
Play thread 2
The map will be null for all future threads
was:
The hrefParams map is cleared and then subsequent requests not properly routed.
Our problem doesn't occur on load, but rather occurs sometime after when two
requests hit cleanMapCtx in the right timing to have one clear out the map as
the other is grabbing the entry set, resulting in the second thread doing a
clear but having nothing to put back in. Then all subsequent requests don't
get routed properly.
This is similar to https://issues.apache.org/jira/browse/ABDERA-95 and
https://issues.apache.org/jira/browse/ABDERA-276 but does not occur under load,
just with two threads.
In the comments for that issue, there's a mention of a fix by using the code
from an earlier version. I haven't tested the code mentioned from 0.4.0, but
from looking at it the hrefParams isn't being modified, so that would seem to
solve our problem as well. I'm attaching the diff for the fix that we used,
which was to return the new map instance with the cleaned keys instead of
altering and returning the hrefParams.
> server RouteManager threading: MapCtx parameters cleared and replaced with
> empty parameters
> -------------------------------------------------------------------------------------------
>
> Key: ABDERA-294
> URL: https://issues.apache.org/jira/browse/ABDERA-294
> Project: Abdera
> Issue Type: Bug
> Affects Versions: 1.1.2
> Environment: Abdera 1.1.2
> Reporter: Bob Fields
> Fix For: 1.2
>
> Attachments: RouteManager.patch
>
>
> The hrefParams map is cleared and then subsequent requests not properly
> routed. Our problem doesn't occur on load, but rather occurs sometime after
> when two requests hit cleanMapCtx in the right timing to have one clear out
> the map as the other is grabbing the entry set, resulting in the second
> thread doing a clear but having nothing to put back in. Then all subsequent
> requests don't get routed properly.
>
> This is similar to https://issues.apache.org/jira/browse/ABDERA-95 and
> https://issues.apache.org/jira/browse/ABDERA-276 but does not occur under
> load, just with two threads.
> In the comments for that issue, there's a mention of a fix by using the code
> from an earlier version. I haven't tested the code mentioned from 0.4.0, but
> from looking at it the hrefParams isn't being modified, so that would seem to
> solve our problem as well. I'm attaching the diff for the fix that we used,
> which was to return the new map instance with the cleaned keys instead of
> altering and returning the hrefParams.
> The problem we experienced was that the ATOM feed would intitally be working,
> but then would start returning 404 errors. We found that this was caused by
> the hrefParams property of the AtomCollectionAdapter being corrupted (cleared
> out) by the cleanMapCtx method in RouteManager. This occured when mutliple
> threads hit RouteManager.cleanMapCtx in close succession, such that the
> first thread cleans the shared map as the second is trying to iterate over
> the entries in the map. The second thread will then clear the map, but have
> nothing to put back in it, resulting in the map being empty for all future
> requests.
> We ran into this fairly often in testing with a decent load, but the easiest
> way to recreate this on demand is to debug remotely and manually step through
> two threads so that they hit at the right time. I've included the steps I
> used below.
> Steps to re-create by remote debugging:
> Set breakpoint in RouteManager.cleanMapCtx line 176
> In thread 1, step through to after the map has been cleared (line 181)
> In thread 2, step through to line 180. This thread will now have an empty
> map, since it got the entrySet after the first map was cleared, but before
> the putAll
> Play thread 1
> Play thread 2
> The map will be null for all future threads
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
