You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Ellis Pritchard (JIRA)" <ji...@apache.org> on 2007/01/04 16:24:27 UTC
[jira] Created: (COCOON-1977) Unsynchronized access to HashMap in
ResourceReader
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.10, 2.1.9, 2.1.11-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: versions in Jira
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke wrote:
>
> How it must be handled:
> 1. As soon as a bug gets fixed the "Current SVN" version MUST be removed
> from "Affects versions". As it is already fixed having it there is also
> no longer correct.
> 2. The X.Y.Z-dev version must be renamed to X.Y.Z after a release and a
> new entry created for X.Y.Z+1-dev and not the other way around.
>
> Otherwise we provide wrong information on issues in Jira.
>
> I'll fix the above for 2.1.10-dev => 2.1.11-dev.
>
> Jörg
>
Thanks Jörg for fixing this! It must be me who did this wrong this time,
sorry for that! (I thought I did it right). Will hopefully never happen
again.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
versions in Jira
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.01.2007 00:21, Jörg Heinicke (JIRA) wrote:
> Resolution: Fixed
> Fix Version/s: 2.2-dev (Current SVN)
> 2.1.11-dev (current SVN)
I wonder how we manage those versions. It seems to be quite strange:
Issues fixed in 2.1.9: https://issues.apache.org/jira/browse/COCOON-1700
https://issues.apache.org/jira/browse/COCOON-1806
In 2.1.10: https://issues.apache.org/jira/browse/COCOON-1879
In 2.1.11-dev: https://issues.apache.org/jira/browse/COCOON-1977
It seems that both the renaming and the handling of the properties
themselves are done wrongly:
1. 2.1.9-dev got correctly renamed to 2.1.9, but having 2.1.9-dev in
"Affects Versions" lets it view quite strange as the bug seems to be in
2.1.9 and is fixed in that version as well.
2. For 2.1.10-dev it seems to be even worse. I guess it was directly
renamed to 2.1.11-dev - which now makes all version infos in those bugs
wrong.
How it must be handled:
1. As soon as a bug gets fixed the "Current SVN" version MUST be removed
from "Affects versions". As it is already fixed having it there is also
no longer correct.
2. The X.Y.Z-dev version must be renamed to X.Y.Z after a release and a
new entry created for X.Y.Z+1-dev and not the other way around.
Otherwise we provide wrong information on issues in Jira.
I'll fix the above for 2.1.10-dev => 2.1.11-dev.
Jörg
[jira] Closed: (COCOON-1977) Unsynchronized access to HashMap in
ResourceReader
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörg Heinicke closed COCOON-1977.
---------------------------------
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.11-dev (current SVN)
Fixed as proposed. Thanks for your commitment.
> 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
> Assigned To: Jörg Heinicke
> Priority: Critical
> Fix For: 2.1.11-dev (current SVN), 2.2-dev (Current SVN)
>
>
> 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
[jira] Assigned: (COCOON-1977) Unsynchronized access to HashMap in
ResourceReader
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörg Heinicke reassigned COCOON-1977:
-------------------------------------
Assignee: Jörg Heinicke
> 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
> Assigned To: Jörg Heinicke
> 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
[jira] Updated: (COCOON-1977) Unsynchronized access to HashMap in
ResourceReader
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörg Heinicke updated COCOON-1977:
----------------------------------
Fix Version/s: (was: 2.1.10)
2.1.11-dev (Current SVN)
Affects Version/s: (was: 2.1.11-dev (Current SVN))
(was: 2.2-dev (Current SVN))
> 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
> Reporter: Ellis Pritchard
> Assigned To: Jörg Heinicke
> Priority: Critical
> Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>
>
> 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
[jira] Updated: (COCOON-1977) Unsynchronized access to HashMap in
ResourceReader
Posted by "Jörg Heinicke (JIRA)" <ji...@apache.org>.
[ 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