[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-tabpanel&focusedCommentId=12667919#action_12667919 ] imran pariyani commented on COCOON-2173: ok we add this pipe to our pipeline 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: > > > > label="b"> > > > > > > > > > > > > > > > > > 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] > (/samples/reproduceMultipleThreads/productOfferForDevice/58840/) > PoolThread-6/AbstractCachingProcessingPipeline: generating lock > 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 > > INFO (2008-03-13) 13:50.16:075 [sitemap] > (/sampl
[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-tabpanel&focusedCommentId=12667811#action_12667811 ] imran pariyani commented on COCOON-2173: hi .. well i tried all different combination with my to set this attribute locking to false .. but some how it dosent consider it .. 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 > 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: > > > > label="b"> > > > > > > > > > > > > > > > > > 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] > (/samples/reproduceMultipleThreads/productOfferForDevice/58840/) > PoolThread-6/AbstractCachingProcessingPipeline: generating lock > PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/58840.xml?pipelinehash=-499603111986478_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/bui
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] 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] 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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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] 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: 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.
Re: multithreaded Content Aggregator migration from 2.1 to 2.2
Hello,
we have come across this issue .. i posted it on user mailing list and
some one from there suggested me to post it here since it seems to be
bug in cocoon 2.2 .. its a very crucial issue for us.. we cant upgrade
to 2.2 unless we some how solve or find a work around for this issue ..
we have multithreaded Content Aggregator which is based on the
CIncludeTransformer and it also implements CacheableProcessingComponent
for caching .. it used to work fine for cocoon 2.1.x but with cocoon 2.2
it gives strange error .. it is actually a generator and it gives error
in the generate method ..
the code where it gives error
// generate...
for (Part part : this.parts) {
if (this.manager.hasService(IncludeCacheManager.ROLE)) {
part.uri = this.cacheManager.load(part.uri,
this.cachingSession);
} else {
this.getLogger().error(
"The ContentAggregator: aggregator cannot
find the IncludeCacheManager");
}
}
// aggregate...
StreamPipe streamPipe = new StreamPipe(this.contentHandler);
for (Part part : this.parts) {
streamPipe.firstElement(part.element, this.rootElement,
part.stripRootElement);
try {
System.out.println("ParallelContentAgg.part.uri:" +
part.uri);
this.cacheManager.stream(part.uri,
this.cachingSession, streamPipe);
} finally {
streamPipe.lastElement(part.element);
}
}
it gives the following error
Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name
'scopedTarget.org.apache.cocoon.el.objectmodel.ObjectModel': Scope
'request' is not active for the current thread; consider defining a
scoped proxy for this bean if you intend to refer to it from a
singleton; nested exception is java.lang.IllegalStateException: No
thread-bound request found: Are you referring to request attributes
outside of an actual web request? If you are actually operating within a
web request and still receive this message,your code is probably running
outside of DispatcherServlet/DispatcherPortlet: In this case, use
RequestContextListener or RequestContextFilter to expose the current
request.
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:293)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at
org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:184)
at $Proxy2.cleanupLocalContext(Unknown Source)
at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:382)
at
org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:111)
at
org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:170)
at
org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:63)
at
org.apache.cocoon.transformation.helpers.DefaultIncludeCacheManager$LoaderThread.run(DefaultIncludeCacheManager.java:415)
at
org.apache.cocoon.environment.CocoonRunnable.doRun(CocoonRunnable.java:64)
at
org.apache.cocoon.environment.internal.EnvironmentHelper$AbstractCocoonRunnable.run(EnvironmentHelper.java:453)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
... 1 more
Grzegorz Kossakowski wrote:
Imran Pariyani pisze:
Hi
Hi Imran,
last night i wasted 5 hrs overs this without any success .. i guess
it has something to do with passing the RequestContextListener to the
spring context .. i have initialized the listener in my web.xml and
also added the config in applicationcontext.xml .. i checked
everything on my end .. everything seems to be fine .. is something
wrong with the cachemanager present in cocoon ?
any help will be greatly appreciated !! ..
Unfortunately, it looks like you stumbled across rather complicated
(and obscure) bug. It's related to the fact how Spring's request scope
works (objects are tied to the thread). If you run multithreaded
aggregation then child threads don't have an access to beans defined
with 'request' scope because they are visible only in parent thread.
More details below...
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:382)
The failing code is:
if (touchedOM) {
//Because of complicated flow of this source it must
maintain the cleaness of OM on its own
ObjectModel newObjectModel;
try {
newObjectModel =
(ObjectModel)manager.lookup(ObjectModel.ROLE);
[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". 16 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] 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)
[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)
[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
