[jira] Commented: (COCOON-2173) AbstractCachingProcessingPipeline: Two requests can deadlock each other
[
https://issues.apache.org/jira/browse/COCOON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667811#action_12667811
]
imran pariyani commented on COCOON-2173:
hi .. well i tried all different combination with my map:pipeline to set this
attribute locking to false .. but some how it dosent consider it ..
map:pipeline type=caching-point
map:parameter name=locking value=false/
can you please lemme know how do u set it to false .. as i am using a
caching-point pipeline it only considers the params defined in
/core/cocoon-core/src/main/resources/META-INF/cocoon/avalon/cocoon-core-sitemapcomponents.xconf
i.e
map:pipe name=caching-point
src=org.apache.cocoon.components.pipeline.impl.CachingPointProcessingPipeline
parameter name=autoCachingPoint value=On/
/map:pipe
AbstractCachingProcessingPipeline: Two requests can deadlock each other
---
Key: COCOON-2173
URL: https://issues.apache.org/jira/browse/COCOON-2173
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2
Reporter: Alexander Daniel
Attachments: patchFor2.1.11.txt, reproduceMultipleThreads.tar.gz,
reproduceMultipleThreads2.2RC3-SNAPSHOT.tar.gz
Two requests can deadlock each other when they depend on the same resources
which they acquire in a different order. I can reproduce that in Cocoon
2.1.11 and Cocoon 2.2-RC3-SNAPSHOT:
* request A: generating lock for 55933
* request B: generating lock for 58840
* request B: waiting for lock 55933 which is hold by request A
* request A: waiting for lock 58840 which is hold by request B
I can reproduce this behaviour with Apache Bench and following pipeline:
* terminal 1: Apache Bench request A (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
* terminal 2: Apache Bench request B (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
* terminal 3: touching the two data files every second to invalidate the
cache (while true; do echo -n .; touch 55933.xml 58840.xml; sleep 1; done)
* pipeline:
map:pipeline type=caching
map:match pattern=productOfferForDevice*/*/
map:generate src=cocoon:/exists/{2}.xml label=a/
map:transform type=xsltc src=productOfferIncludeDevice.xsl
label=b
map:parameter name=noInc value={1}/
/map:transform
map:transform type=include label=c/
map:serialize type=xml/
/map:match
map:match pattern=exists/**
map:act type=resource-exists
map:parameter name=url value={1} /
map:generate src={../1} /
map:serialize type=xml /
/map:act
!-- not found --
map:generate src=dummy.xml /
map:serialize type=xml /
/map:match
/map:pipeline
After some seconds the deadlock occurs ==
* Apache Bench requests run into a timeout
* I can see following pipe locks in the default transient store:
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/58840.xml?pipelinehash=-499603111986478_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/58840.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
I added some logging to AbstractCachingProcessingPipeline.java which
reconfirms the explanations above:
INFO (2008-03-13) 13:50.16:072 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
INFO (2008-03-13) 13:50.16:074 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
[jira] Commented: (COCOON-2173) AbstractCachingProcessingPipeline: Two requests can deadlock each other
[
https://issues.apache.org/jira/browse/COCOON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667919#action_12667919
]
imran pariyani commented on COCOON-2173:
ok we add this pipe to our pipeline
map:pipes
map:pipe name=caching-point-nolocking
src=org.apache.cocoon.components.pipeline.impl.CachingPointProcessingPipeline
parameter name=autoCachingPoint value=On/
parameter name=locking value=false/
/map:pipe
/map:pipes
overriding the one in
/core/cocoon-core/src/main/resources/META-INF/cocoon/avalon/cocoon-core-sitemapcomponents.xconf
..
AbstractCachingProcessingPipeline: Two requests can deadlock each other
---
Key: COCOON-2173
URL: https://issues.apache.org/jira/browse/COCOON-2173
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2
Reporter: Alexander Daniel
Attachments: patchFor2.1.11.txt, reproduceMultipleThreads.tar.gz,
reproduceMultipleThreads2.2RC3-SNAPSHOT.tar.gz
Two requests can deadlock each other when they depend on the same resources
which they acquire in a different order. I can reproduce that in Cocoon
2.1.11 and Cocoon 2.2-RC3-SNAPSHOT:
* request A: generating lock for 55933
* request B: generating lock for 58840
* request B: waiting for lock 55933 which is hold by request A
* request A: waiting for lock 58840 which is hold by request B
I can reproduce this behaviour with Apache Bench and following pipeline:
* terminal 1: Apache Bench request A (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
* terminal 2: Apache Bench request B (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
* terminal 3: touching the two data files every second to invalidate the
cache (while true; do echo -n .; touch 55933.xml 58840.xml; sleep 1; done)
* pipeline:
map:pipeline type=caching
map:match pattern=productOfferForDevice*/*/
map:generate src=cocoon:/exists/{2}.xml label=a/
map:transform type=xsltc src=productOfferIncludeDevice.xsl
label=b
map:parameter name=noInc value={1}/
/map:transform
map:transform type=include label=c/
map:serialize type=xml/
/map:match
map:match pattern=exists/**
map:act type=resource-exists
map:parameter name=url value={1} /
map:generate src={../1} /
map:serialize type=xml /
/map:act
!-- not found --
map:generate src=dummy.xml /
map:serialize type=xml /
/map:match
/map:pipeline
After some seconds the deadlock occurs ==
* Apache Bench requests run into a timeout
* I can see following pipe locks in the default transient store:
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/58840.xml?pipelinehash=-499603111986478_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/58840.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
I added some logging to AbstractCachingProcessingPipeline.java which
reconfirms the explanations above:
INFO (2008-03-13) 13:50.16:072 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
INFO (2008-03-13) 13:50.16:074 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
INFO (2008-03-13) 13:50.16:075 [sitemap]
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636376#action_12636376 ] imran pariyani commented on COCOON-2216: hi Grzegorz, in the article there was something about Lack of a Standard Thread-Pooling Library .. now there is a standard which comes with the JDK .. i don't know if we are using that or not .. but it is possible that it might take care of the ThreadLocal variables .. just a thought. should i forward this discussion to the dev mailing list ? IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636059#action_12636059 ] imran pariyani commented on COCOON-2216: Hi Grzegorz, were u able to reproduce the problem with the second test case and with your patch applied ? IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636231#action_12636231 ] imran pariyani commented on COCOON-2216: sorry for that typo .. but for me after changing it to attribute also its still the same .. i mean the fisrt time the page is loaded the attributes and the parameters are there .. but then when u keep clicking the links with the parameters most of the time the attributes are missing .. on each component at the ends there are links like: With Parameter 1 With parameter 1 and 2 With parameter 1,2 and 3 those are the three links .. and as i said if u keep clicking them most of the time the parameters and the attributes are missing .. without the params also the attribute should always be there .. but if i keep refreshing the page the attribute is also often missing did u change anything except for the changes present in the patch ? i have the source from your git repo so i think it should be the recent one .. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635390#action_12635390 ] imran pariyani commented on COCOON-2216: Hi Grzegorz, thanks a bunch .. i will right away either apply the patch or else check out ur branch ... will let you know when i am done with testing .. thanks once again for ur efforts .. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635531#action_12635531 ] imran pariyani commented on COCOON-2216: hi , tried to apply the patch to the current trunk .. but it keeps giving this error ERROR [main] (ContextLoader.java:214) - Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.ajax.impl.servlet': Invocation of init method failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not create configuration for TreeProcesoor; nested exception is java.net.MalformedURLException: unknown protocol: blockcontext something seems to be broken in the trunk ... i will get the version from git and try to build with that ... in the mean while the error above is it because of the new dojo which we integrated with cocoon .. it builds successfully but when starting jetty it throws that error .. do u get the same error when starting the jetty server ? IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635585#action_12635585 ] imran pariyani commented on COCOON-2216: Hi Grzegorz, After building cocoon from git repo it works .. the generation is taking palce in parallel and also the OM is different for all the child threads but there is still some problem with the cocoon.request object ... somehow for some child thread the cocoon.request attributes are lost (sometimes)... is it that the cocoon.request attributes are not copied over to that OM which is created for that specific child thread? IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635602#action_12635602 ] imran pariyani commented on COCOON-2216: well i can modify that test case so that it will consider some request attributes as well ... but other then that it works great .. thanks :) and ya you were right about that cocoon-servlet-service-impl had an old version of it in my repo ... i will do the necessary changes to the test case and upload them here. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] imran pariyani updated COCOON-2216: --- Attachment: test-block.zip IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] imran pariyani updated COCOON-2216: --- Attachment: test-webapp.zip IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, multi-thread-simple-28.09.2008.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip, test-webapp.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[
https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635633#action_12635633
]
imran pariyani commented on COCOON-2216:
have attached both the blocks again ... actually webapp block is the same
without any changes ..
below the components there are three links .. one with one param , second one
with 2 params and the thrid one with 3 params ... and i set one request
attribute in the class pagegenerator ... so the request attribute should always
be displayed .. and the request parameters depends on the link you click ... so
if you click the first link then the first parameter should be displayed and so
on ...
but as you will notice the attribute and the parameters are displayed only
sometimes .. very rarely..
i access the params in the jx pages .. with
${cocoon.request.getParameter('param1')} so they should always be there if they
are present in the url ...
IncludeCacheManager can not perfom parallel includes
Key: COCOON-2216
URL: https://issues.apache.org/jira/browse/COCOON-2216
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.2-dev (Current SVN)
Reporter: Christoph Gaffga
Assignee: Grzegorz Kossakowski
Attachments: cocoon-trunk.patch,
multi-thread-simple-28.09.2008.patch,
ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-block.zip,
test-webapp.zip, test-webapp.zip
Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple
sources from other cocoon pipelines into one (similar to the aggregator) is
not working anymore.
We also posted our problem to the mailing list, got little feedback but it
brought us on the right way...
see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html
I found out that it's a problem with the DefaultIncludeCacheManager, that can
not do parallel inclusion of cocoon-pipelines anymore. I checked several
classes where inclusion is used. In the aggregator parallel inclusion is not
an option anymore, in CIncludeTransformer the IncludeCacheManager is used,
but it can't do parallel inclusion. In the new IncludeTransfomer parallel
inclusion is supported, but it does not use caching as it does not use the
IncludeCacheManager...
But we needed caching AND parallel processing, so I tried to find out what's
broken in the DefaultIncludeCacheManager:
and it seems that the ThreadLocal variables are not initialized for the child
threads that do the inclusion. Neither the spring context nor the old
environment stuff was initialized. And all the source resolving was done
outside the child thread and that way using the wrong thread context.
We were able to fix that issue by small changes to DefaultIncludeCacheManager
and IncludeCacheManagerSession. It would be great if somebody could apply
this patch so we don'T have to patch every cocoon version again and again...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631632#action_12631632 ] imran pariyani commented on COCOON-2216: any luck with this issue ? .. it is a major performance blocker for our application .. if not a fix some small workaround will also do for the time being till its fixed ... we do have a small workaround but its quite ugly .. and with that we cant generate cforms in parallel .. IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12624395#action_12624395 ] imran pariyani commented on COCOON-2216: Hi Grzegorz, I appreciate your efforts Thanks .. would like to see the implementation of the method synchronizeStack() .. hope to see it by next friday :) IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623350#action_12623350 ] imran pariyani commented on COCOON-2216: great !! .. i will wait for the patches .. thanks :) IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Assignee: Grzegorz Kossakowski Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] imran pariyani updated COCOON-2216: --- Attachment: test-webapp.zip webapp block IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] imran pariyani updated COCOON-2216: --- Attachment: test-block.zip test block IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] imran pariyani updated COCOON-2216: --- Attachment: cocoon-trunk.patch for running the testcases u will have to first apply this patch file IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615481#action_12615481 ] imran pariyani commented on COCOON-2216: have attached the test case to reproduce the error .. i have attached three files .. test-block is the main block .. webapp is for running that block .. before that u will have to apply the patch cocoon-trunk.patch to the cocoon other wise it wont work at all ... for both the block perform mvn install .. and then for from inside the webapp block mvn jetty:run so the page http://localhost:/test-block/index.html is generated using the parallel generator .. if ur lucky and dont get the error the first time then just refresh and am sure the error will be there .. there are five components included in that page ... out of which 4 are normal jx components and the fifth one is cforms component ... all the jx component have been assigned different instance of the same object but still the properties displayed on the page shows the same value(they should be different) .. if u execute query for these components individually then they appear without any error .. links for querying them individually [jx components .. shows xml output .. forgot to add the pipeline to serialize it to html.. u can add one] http://localhost:/test-block/showjx http://localhost:/test-block/showjx1 http://localhost:/test-block/showjx2 http://localhost:/test-block/showjx3 [cforms component] http://localhost:/test-block/form2bean.flow most of the time we get the error Caused by: org.apache.commons.jxpath.JXPathException: No value for xpath: $cocoon/continuation/id its because the objectmodel is being changed by all the components simultaneously ...the error is there in the log file not on the page .. on the page it will just ignore that component IncludeCacheManager can not perfom parallel includes Key: COCOON-2216 URL: https://issues.apache.org/jira/browse/COCOON-2216 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Christoph Gaffga Attachments: cocoon-trunk.patch, ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple sources from other cocoon pipelines into one (similar to the aggregator) is not working anymore. We also posted our problem to the mailing list, got little feedback but it brought us on the right way... see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html I found out that it's a problem with the DefaultIncludeCacheManager, that can not do parallel inclusion of cocoon-pipelines anymore. I checked several classes where inclusion is used. In the aggregator parallel inclusion is not an option anymore, in CIncludeTransformer the IncludeCacheManager is used, but it can't do parallel inclusion. In the new IncludeTransfomer parallel inclusion is supported, but it does not use caching as it does not use the IncludeCacheManager... But we needed caching AND parallel processing, so I tried to find out what's broken in the DefaultIncludeCacheManager: and it seems that the ThreadLocal variables are not initialized for the child threads that do the inclusion. Neither the spring context nor the old environment stuff was initialized. And all the source resolving was done outside the child thread and that way using the wrong thread context. We were able to fix that issue by small changes to DefaultIncludeCacheManager and IncludeCacheManagerSession. It would be great if somebody could apply this patch so we don'T have to patch every cocoon version again and again... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2186) Suggest list .. initial value not being displayed
Suggest list .. initial value not being displayed -- Key: COCOON-2186 URL: https://issues.apache.org/jira/browse/COCOON-2186 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.11 Reporter: imran pariyani Priority: Minor For the forms field of type suggest with a suggestion list the initial value is not being displayed ... this dint happen for version 2.1.10 .. but when i upgraded to version 2.1.11 it no longer sets the initial value .. this bug is also present for the sample http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/do-suggest.flow Initial value of the widget is 16, the widget must show Bruno Dumon. fd:datatype base=integer/ fd:initial-value16/fd:initial-value fd:suggestion-list type=javascript after debugging i found out that the widgets value is being set but it isnt passed on to DOJO as initial value when the DOJO widget is created .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[ https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526472 ] imran pariyani commented on COCOON-1579: I am also facing a similar problem but in my case the scenario is a bit different . I have a form which i submit and if everything is ok then in the flowscript i use sendpage(some pipeline).. this pipeline is again with a form and it calls the flowscript which generates a new continuation .. now if i try to submit this form i get a nullpointerexception .. below is the stacktrace .. i tried the workaround mentioned here .. but still i get the same error :( Any help would be appreciated java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578) at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145) at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677) at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180) at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:161) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:159) at org.mozilla.javascript.Context.call(Context.java:489) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1556) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1526) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter .java:839) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java :124) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:47) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :235) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :177) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:47) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode .java:69) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :235) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java :177) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:253) at org.apache.cocoon.Cocoon.process(Cocoon.java:699) at
[jira] Issue Comment Edited: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[
https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526472
]
pariyani edited comment on COCOON-1579 at 9/11/07 10:26 AM:
--
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816
i just tried the same with cocoon-2.1.10 samples .. in the
blocks/forms/flow/binding_example.js
change in the method form2bean(form) the line with sendpage
cocoon.sendPage(form2bean.flow, { form2bean: bean });
send it to any pipeline with cforms and the if u try to submit that form u get
to following exception in the method boldjsGet_request/bold:
Sitemap: error calling continuation
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:575)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:161)
at
org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340)
at
org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:159)
at org.mozilla.javascript.Context.call(Context.java:489)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1556)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1526)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:839)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:124)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
was (Author: pariyani):
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown
[jira] Issue Comment Edited: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[
https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526472
]
pariyani edited comment on COCOON-1579 at 9/11/07 10:26 AM:
--
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816
i just tried the same with cocoon-2.1.10 samples .. in the
blocks/forms/flow/binding_example.js
change in the method form2bean(form) the line with sendpage
cocoon.sendPage(form2bean.flow, { form2bean: bean });
send it to any pipeline with cforms and the if u try to submit that form u get
to following exception in the method jsGet_request:
Sitemap: error calling continuation
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:575)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1677)
at
org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:180)
at
org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1315)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1337)
at
org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1326)
at
org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:2816)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:161)
at
org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340)
at
org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758)
at
org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:159)
at org.mozilla.javascript.Context.call(Context.java:489)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1556)
at
org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1526)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:839)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:124)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
was (Author: pariyani):
I am also facing a similar problem but in my case the scenario is a bit
different . I have a form which i submit and if everything is ok then in the
flowscript i use sendpage(some pipeline).. this pipeline is again with a form
and it calls the flowscript which generates a new continuation .. now if i try
to submit this form i get a nullpointerexception .. below is the stacktrace ..
i tried the workaround mentioned here .. but still i get the same error :(
Any help would be appreciated
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:578)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
