You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Jörg Heinicke (JIRA)" <ji...@apache.org> on 2007/01/04 22:13:28 UTC
[jira] Updated: (COCOON-1977) Unsynchronized access to HashMap in
ResourceReader
[ https://issues.apache.org/jira/browse/COCOON-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörg Heinicke updated COCOON-1977:
----------------------------------
Affects Version/s: 2.2-dev (Current SVN)
I'm wondering what this "caching" does buy us at all? Can somebody tell in which cases the reader is really faster? From what I understand in those cases, when one request.getRequestURI() resolves to different inputSources. I'd remove documents and quickTest completely.
> Unsynchronized access to HashMap in ResourceReader
> --------------------------------------------------
>
> Key: COCOON-1977
> URL: https://issues.apache.org/jira/browse/COCOON-1977
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.1.9, 2.1.10, 2.1.11-dev (current SVN), 2.2-dev (Current SVN)
> Reporter: Ellis Pritchard
> Priority: Critical
>
> I've just had a production server lock up, and when I forced a stack trace I saw lots of these:
> "TP-Processor30" daemon prio=5 tid=0x00ce2a50 nid=0x52 runnable [bccfd000..bccffc30]
> at java.util.HashMap.get(HashMap.java:325)
> at org.apache.cocoon.reading.ResourceReader.getLastModified(ResourceReader.java:238)
> at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:468)
> at org.apache.cocoon.components.treeprocessor.sitemap.ReadNode.invoke(ReadNode.java:84)
> etc.
> What I've noticed is that the 'documents' HashMap in ResourceReader (a static member) is accessed in an unsynchronized fashion; neither is documents synchronized, or are the puts and gets to it. This is a potential (and actual!!) hazard, and can lead to crashes or hangs.
> Suggest that line 94 of ResourceReader.java is changed from:
> private static final Map documents = new HashMap();
> to
> private static final Map documents = Collections.synchronizedMap(new HashMap());
> Work-around:
> enable quick-modified-test in configuration which by-passes use of the document URI cache:
> <map:reader logger="sitemap.reader.resource" name="resource" pool-max="32" src="org.apache.cocoon.reading.ResourceReader">
> <quick-modified-test>true</quick-modified-test>
> </map:reader>
--
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
Re: [jira] Updated: (COCOON-1977) Unsynchronized access to HashMap
in ResourceReader
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.01.2007 22:13, Jörg Heinicke (JIRA) wrote:
> Jörg Heinicke updated COCOON-1977:
> ----------------------------------
>
> Affects Version/s: 2.2-dev (Current SVN)
>
> I'm wondering what this "caching" does buy us at all? Can somebody
> tell in which cases the reader is really faster? From what I understand
> in those cases, when one request.getRequestURI() resolves to different
> inputSources. I'd remove documents and quickTest completely.
Found the original commit [1] and the thread where it was discussed
before [2]. But I can not really see how it helps to optimize and
whether it is an optimization at all.
With the document list but without quickTest it would behave differently
if the requestURI would lead to a different InputSource - I wonder if
this can happen. Without the document list it would not behave
differently than now I think as no check against a former
InputSource.getURI() can be done. So what's up with that stuff? Is that
still valid?
Regards
Jörg
PS: Happy New Year btw. :)
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104019898011748&w=4
[2] http://marc.theaimsgroup.com/?t=102854688200001&r=1&w=4