[jira] Commented: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581012#action_12581012 ] Antonio Gallardo commented on COCOON-2163: -- Patch applied with minor fixes in 2.1.12-dev Widget Label is not Show/Hide when we change the widget state in ajax mode -- Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Assignee: Antonio Gallardo Priority: Minor Attachments: widget_states_patch.txt There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[continuum] BUILD ERROR: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=67941projectId=51 Build statistics: State: Error Previous State: Ok Started at: Thu 20 Mar 2008 23:31:26 -0700 Finished at: Fri 21 Mar 2008 00:00:27 -0700 Total time: 29m 0s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: REPORT of '/repos/asf/!svn/vcc/default': Could not read chunk size: connection was closed by server. (http://svn.apache.org) ---
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 21 March 12:42 PM Using Forrest 0.9-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2008-03-21 12:12:23 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.9-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Apr 10 05:50:24 GMT+00:00 2007 [get] . [get] last modified = Wed Apr 11 02:07:04 GMT+00:00 2007 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Fri Feb 15 13:06:17 GMT+00:00 2008 [get] Not modified - so not downloaded [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to
Re: ForrestBot build for cocoon-docs FAILED
Thorsten Scherler pisze: On Thu, 2008-03-20 at 12:34 +, [EMAIL PROTECTED] wrote: ... [java] X [0] 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html BROKEN: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy (Is a directory) ... [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke Seems that the 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html file does not exist anymore. Did somebody moved it, or deleted it? It's located at: 2.1/userdocs/profile-generator.html for at least two years[1] now so I suppose it's something broken at your side. [1] http://svn.apache.org/viewvc/cocoon/site/site/2.1/userdocs/profile-generator.html?view=log -- Grzegorz
[jira] Commented: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581072#action_12581072 ] Grzegorz Kossakowski commented on COCOON-2179: -- Reinhard, as you are busy with preparing the release I decided to give this one a shoot. :-) Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2179: Assignee: Grzegorz Kossakowski Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Assignee: Grzegorz Kossakowski Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[continuum] BUILD ERROR: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=68001projectId=51 Build statistics: State: Error Previous State: Ok Started at: Fri 21 Mar 2008 04:51:30 -0700 Finished at: Fri 21 Mar 2008 06:21:32 -0700 Total time: 1h 30m 2s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Exception: Cannot checkout sources. Exception while executing SCM command. Error while executing command. Error while executing external command, process killed. null
[jira] Created: (COCOON-2180) Corona - A proposal for a reimplementation
Corona - A proposal for a reimplementation -- Key: COCOON-2180 URL: https://issues.apache.org/jira/browse/COCOON-2180 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Steven Dolg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2180) Corona - A proposal for a reimplementation
[ https://issues.apache.org/jira/browse/COCOON-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Dolg updated COCOON-2180: Attachment: corona.zip Corona - A proposal for a reimplementation -- Key: COCOON-2180 URL: https://issues.apache.org/jira/browse/COCOON-2180 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Steven Dolg Attachments: corona.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2180) Corona - A proposal for a reimplementation
[ https://issues.apache.org/jira/browse/COCOON-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz reassigned COCOON-2180: -- Assignee: Reinhard Poetz Corona - A proposal for a reimplementation -- Key: COCOON-2180 URL: https://issues.apache.org/jira/browse/COCOON-2180 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Steven Dolg Assignee: Reinhard Poetz Attachments: corona.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2180) Corona - A proposal for a reimplementation
[ https://issues.apache.org/jira/browse/COCOON-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581075#action_12581075 ] Reinhard Poetz commented on COCOON-2180: As discussed on the mailing list, I'm going to put Corona into the whiteboard. Corona - A proposal for a reimplementation -- Key: COCOON-2180 URL: https://issues.apache.org/jira/browse/COCOON-2180 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Steven Dolg Assignee: Reinhard Poetz Attachments: corona.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581095#action_12581095 ] Grzegorz Kossakowski commented on COCOON-2179: -- First observations: it looks like it's problem with recycling poolable components (AbstractProcessingPipeline in this case). I constantly see something like that in logs: [ERROR] PoolableFactoryBean - Exception while putting component '[EMAIL PROTECTED]' back into the pool. 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.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.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:102) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:61) at $Proxy11.putBackIntoAvalonPool(Unknown Source) at org.apache.cocoon.core.container.spring.avalon.AvalonServiceManager.release(AvalonServiceManager.java:73) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:686) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:74) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:1017) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean.enteringPool(PoolableFactoryBean.java:259) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean.putIntoPool(PoolableFactoryBean.java:229) at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.run(PoolableProxyHandler.java:84) at org.springframework.web.context.request.AbstractRequestAttributes.executeRequestDestructionCallbacks(AbstractRequestAttributes.java:76) [...] I'm still not sure where is the real cause of this problem in Spring logic or in Avalon Bridge or in RCL. Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Assignee: Grzegorz Kossakowski Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[continuum] BUILD ERROR: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=68007projectId=51 Build statistics: State: Error Previous State: Error Started at: Fri 21 Mar 2008 07:44:12 -0700 Finished at: Fri 21 Mar 2008 08:27:28 -0700 Total time: 43m 15s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: REPORT of '/repos/asf/!svn/vcc/default': Could not read chunk size: connection was closed by server. (http://svn.apache.org) ---
Re: [continuum] BUILD ERROR: Apache Cocoon [build root]
Continuum VMBuild Server pisze: Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: REPORT of '/repos/asf/!svn/vcc/default': Could not read chunk size: connection was closed by server. (http://svn.apache.org) --- FYI: It's been already reported, see https://issues.apache.org/jira/browse/INFRA-1565 -- Grzegorz Kossakowski
[jira] Closed: (COCOON-2179) Exception generator doesn't work properly
[ https://issues.apache.org/jira/browse/COCOON-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2179. Resolution: Duplicate Affects version (Component): Parent values: Cocoon Core(10151). Level 1 values: 2.2.0-RC2(10309). Fix version (Component): Parent values: Cocoon Core(10227). Level 1 values: 2.2.0-RC2(10303). It turns out that commit made by Carsten in r543066 did not incorporate essential change proposed originally by Alexander Klimetschek. This problem turns out to be the reincarnation of COCOON-2070 that has never been fixed. Exception generator doesn't work properly - Key: COCOON-2179 URL: https://issues.apache.org/jira/browse/COCOON-2179 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Assignee: Grzegorz Kossakowski Priority: Blocker I run across some obscure behaviour, when I use the exception generator: The problem is that it only works every second request. When it fails, following exception is thrown: Caused by: org.apache.cocoon.ProcessingException: Generator already set. Cannot set genera tor 'exception' at map:generate type=exception - file:///F:/os/cocoon/trunk/blocks/cocoon-it/. /src/main/resources/COB-INF/sitemap.xmap:211:43 at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setGenerator(A bstractProcessingPipeline.java:205) I don't remember that I have seen this with RC2. I added a sample to cocoon-it and a test case to cocoon-webapp (org.apache.cocoon.it.sitemap.ErrorHandlingTest). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2070) Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions)
[ https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reopened COCOON-2070: -- Assignee: Grzegorz Kossakowski (was: Carsten Ziegeler) In r543066 slightly modified patch from Alexander has been committed but this small modification lead to the situation that original problem has *never* been fixed. Line: RequestContextHolder.currentRequestAttributes().removeAttribute(this.attributeName, RequestAttributes.SCOPE_REQUEST); has been *copied* to the enclosing if clause but it should has been *moved*. See diff available at http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableProxyHandler.java?r1=490762r2=543066diff_format=h Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions) -- Key: COCOON-2070 URL: https://issues.apache.org/jira/browse/COCOON-2070 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Priority: Blocker Fix For: 2.2-dev (Current SVN) Attachments: poolable-recycle-bug.patch There is a serious bug in o.a.c.core.container.spring.avalon.PoolableProxyHandler (and PoolableFactoryBean) that can lead to exceptions like Cannot set reader. Generator already set. This is because the pipeline impl bean is reused from the pool, but was never recycle()d. The recycle() call is skipped in cases when an exception is thrown by Spring inside PoolableProxyHandler.invoke(putBackIntoAvalonPool) - this exception is simply swalled by both PoolableProxyHandler.run() and PoolableFactoryBean.putIntoPool(). The typical behaviour is that the first call to the pipeline works, but because the components are put back into the pool unrecycled, the next call will fail. If there is lots of activity, you might get a fresh component from the pool and it might work again, so the error seems quite random. The problematic exception happens when RequestContextHolder.currentRequestAttributes() is called when the attributes for the request are null: IllegalStateException(No thread-bound request found:.). The call to that method happens in the putBackIntoAvalonPool case in PoolableProxyHandler.invoke(). The problem is that this code will also be called *after* the request attributes were set to null by the RequestContextListener, because it is registered as a destruction callback, that gets called by Spring after the attribute reset. The real chain of calls is as follows: RequestContextListener.requestDestroyed() RequestContextHolder.setRequestAttributes(null) callDestructionCallbacks() PoolableProxyHandler.run() - which is a destruction callback PoolableFactoryBean.putIntoPool() PoolableFactoryBean.enteringPool() component.recycle() AvalonServiceManager/Selector.release(childComponent) - component releases its childComponent AvalonPoolable.putBackIntoAvalonPool() PoolableProxyHandler.invoke() - intercepts the putBackIntoAvalonPool() call RequestContextHolder.currentRequestAttributes() -- Exception !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2070) Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions)
[ https://issues.apache.org/jira/browse/COCOON-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2070. Resolution: Fixed Affects version (Component): Parent values: Components: Sitemap(10152). Level 1 values: 1.0.0-RC3-dev(10312). Fix version (Component): Parent values: Components: Sitemap(10229). Level 1 values: 1.0.0-RC3-dev(10306). Fixed *definitively* in r639686. Thanks again Alexander for your patch! Releasing of pooled beans might skip recycle() call on aggregated beans (leading to: Generator already set-style exceptions) -- Key: COCOON-2070 URL: https://issues.apache.org/jira/browse/COCOON-2070 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Priority: Blocker Fix For: 2.2-dev (Current SVN) Attachments: poolable-recycle-bug.patch There is a serious bug in o.a.c.core.container.spring.avalon.PoolableProxyHandler (and PoolableFactoryBean) that can lead to exceptions like Cannot set reader. Generator already set. This is because the pipeline impl bean is reused from the pool, but was never recycle()d. The recycle() call is skipped in cases when an exception is thrown by Spring inside PoolableProxyHandler.invoke(putBackIntoAvalonPool) - this exception is simply swalled by both PoolableProxyHandler.run() and PoolableFactoryBean.putIntoPool(). The typical behaviour is that the first call to the pipeline works, but because the components are put back into the pool unrecycled, the next call will fail. If there is lots of activity, you might get a fresh component from the pool and it might work again, so the error seems quite random. The problematic exception happens when RequestContextHolder.currentRequestAttributes() is called when the attributes for the request are null: IllegalStateException(No thread-bound request found:.). The call to that method happens in the putBackIntoAvalonPool case in PoolableProxyHandler.invoke(). The problem is that this code will also be called *after* the request attributes were set to null by the RequestContextListener, because it is registered as a destruction callback, that gets called by Spring after the attribute reset. The real chain of calls is as follows: RequestContextListener.requestDestroyed() RequestContextHolder.setRequestAttributes(null) callDestructionCallbacks() PoolableProxyHandler.run() - which is a destruction callback PoolableFactoryBean.putIntoPool() PoolableFactoryBean.enteringPool() component.recycle() AvalonServiceManager/Selector.release(childComponent) - component releases its childComponent AvalonPoolable.putBackIntoAvalonPool() PoolableProxyHandler.invoke() - intercepts the putBackIntoAvalonPool() call RequestContextHolder.currentRequestAttributes() -- Exception !!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Code freeze
Reinhard Poetz pisze: Ok. Then I will create the release artifacts for cocoon-parent cocoon-servlet-service-impl cocoon-servlet-service-components cocoon-configuration cocoon-spring-configurator this afternoon. Please don't do any commits in the relevant parts of our repository. Thanks! Is the code freeze over? I would like to start working on integration of JNet into SSF. - o - The rest will follow as soon as COCOON-2179 is fixed, if time permits this week otherwise in the first week of April. Done, see r639686. Can we have final release of Cocoon core this week? Reinhard, will you manage to prepare them? :-) -- Grzegorz Kossakowski
Re: Code freeze
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Ok. Then I will create the release artifacts for
cocoon-parent
cocoon-servlet-service-impl
cocoon-servlet-service-components
cocoon-configuration
cocoon-spring-configurator
this afternoon.
Please don't do any commits in the relevant parts of our repository.
Thanks!
Is the code freeze over? I would like to start working on integration of JNet
into SSF.
I released everything except the cocoon-servlet-service-components which depend
on cocoon-core. But this shouldn't be relevant for the JNet integration.
- o -
The rest will follow as soon as COCOON-2179 is fixed, if time permits
this week otherwise in the first week of April.
Done, see r639686.
Can we have final release of Cocoon core this week? Reinhard, will you manage
to prepare them? :-)
no, I won't have time over the Easter break. I will _probably_ continue on
Tuesday.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Code freeze
Reinhard Poetz pisze: I released everything except the cocoon-servlet-service-components which depend on cocoon-core. But this shouldn't be relevant for the JNet integration. Hmmm, it will be relevant because I'll need to move blockcontext source from components to impl. I think that creation of branches for 1.0.0 line is the safest option for now. If they turn out to be superfluous we can always remove them and move to 1.1.0 line definitively. I'll create them right away. Thanks for your hard work Reinhard! -- Grzegorz
trunk's broken?
Hi, Seems like trunk got 'mavenized' to death: $ svn up At revision 639697. $ ./build.sh clean [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon Version: 6 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-tools-modules:pom:5- SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-tools- modules:pom:5-SNAPSHOTat org .apache .maven .project .DefaultMavenProjectBuilder .assembleLineage(DefaultMavenProjectBuilder.java:1264) at org .apache .maven .project .DefaultMavenProjectBuilder .buildInternal(DefaultMavenProjectBuilder.java:749) at org .apache .maven .project .DefaultMavenProjectBuilder .buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org .apache .maven .project .DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java: 537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:511) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org .apache .maven .project .DefaultMavenProjectBuilder .findModelFromRepository(DefaultMavenProjectBuilder.java:573) at org .apache .maven .project .DefaultMavenProjectBuilder .assembleLineage(DefaultMavenProjectBuilder.java:1260) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org .apache .maven .artifact .resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java: 197) at org .apache .maven .artifact .resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java: 73) at org .apache .maven .project .DefaultMavenProjectBuilder .findModelFromRepository(DefaultMavenProjectBuilder.java:526) ... 19 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org .apache .maven .artifact .manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:324) at org .apache .maven .artifact .resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java: 185) ... 21 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Fri Mar 21 12:24:51 EDT 2008 [INFO] Final Memory: 1M/5M [INFO]
CForms 1.1.0 Incompatibility
Hi All, When trying to use trunk version of CForms, found out API incompatibility with previous version. Namely, getLogger() method has disappeared from the JXPathBindingBase class, so any custom binding which uses logger will not compile after upgrade to 1.1.0 version. Shouldn't CForms be (as far as possible) compatible with 1.0 API? If yes... and if there are no objections... I will fix this bug. Vadim
Re: trunk's broken?
Vadim Gritsenko pisze: Hi, Seems like trunk got 'mavenized' to death: LOL. ;-) $ svn up At revision 639697. $ ./build.sh clean [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon Version: 6 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 Yup, looks like some versions got decreased instead of being increased, for example: [maven-release-plugin] prepare for next development iteration Modified: cocoon/trunk/tools/pom.xml Modified: cocoon/trunk/tools/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/pom.xml?rev=639627r1=639626r2=639627view=diff == --- cocoon/trunk/tools/pom.xml (original) +++ cocoon/trunk/tools/pom.xml Fri Mar 21 06:15:09 2008 @@ -30,7 +30,7 @@ relativePath../parent/relativePath /parent artifactIdcocoon-tools-modules/artifactId - version6/version + version5-SNAPSHOT/version I'll try to fix that. -- Grzegorz
Re: trunk's broken?
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
Hi,
Seems like trunk got 'mavenized' to death:
LOL. ;-)
$ svn up
At revision 639697.
$ ./build.sh clean
[INFO] Failed to resolve artifact.
GroupId: org.apache.cocoon
ArtifactId: cocoon
Version: 6
Reason: Unable to download the artifact from any repository
org.apache.cocoon:cocoon:pom:6
Yup, looks like some versions got decreased instead of being increased, for
example
I will increase the version numbers of POM modules after all release artifacts
are created.
I'm fixing the build problems but need some more time for further tests.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Exploring Corona
Today I have added Corona to our whiteboard section in SVN (http://svn.apache.org/repos/asf/cocoon/whiteboard/corona/). It mostly mimicks the existing concepts of pipelines and sitemaps as you know from Cocoon 2.x. The available test cases are a good starting point to explore the sources. We also hope that this email explains some of our ideas. What does already work? === PIPELINE API So far we have created a (minimalistic) pipeline API (o.a.c.c.pipeline.Pipeline [1]) that works based on two fundamental concepts: 1. The first component of a pipeline is of type o.a.c.c.pipeline.component.Starter. The last component is of type o.a.c.c.pipeline.component.Finisher. 2. In order to link components with each other, the first has to be a o.a.c.c.pipeline.component.Producer, the latter a o.a.c.c.pipeline.component.Consumer. When the pipeline links the components, it merely checks whether the above mentioned interfaces are present. So the pipeline does not know about the specifc capabilities or the compatibility of the components. It is the responsibility of the Producer to decide whether a specific Consumer can be linked to it or not (that is, whether it can produce output in the desired format of the Consumer or not). It is also conceivable that a Producer is capable of accepting different types of Consumers and adjust the output format according to the actual Consumer. There are SAX-based components that implement these concepts. These concepts are more general than the implementation of Ccooon 2.x which has explicit methods to set generators, transformers, serializers and readers on pipelines. SITEMAP °°° The sitemap engine works similar like Cocoon 2.x. The o.a.c.c.sitemap.SitemapBuilder reads XML and creates a tree of o.a.c.c.sitemap.node.SitemapNode objects that know their parent node, their child nodes and their parameters. The o.a.c.c.sitemap.node.AbstractSitemapNode handles the node relationships and parameters in a general way. However there are two annotations (@o.a.c.c.sitemap.node.annotations.NodeChild and @o.a.c.c.sitemap.node.annotations.Parameter) to make the access of specific child nodes and parameters more explicit. The ChildNode annotation can be used to store a certain child node in a separate member variable instead of the collection of all children (e.g. o.a.c.c.sitemap.node.PipelineNode receives its ErrorNode in the errorNode member variable). The Parameter annotation works the same way, but causes parameters to be stored in separate member variables (e.g. o.a.c.c.sitemap.node.MatchNode receives its pattern in the pattern member variable). When the sitemap is being executed, the invocation traverses the tree of SitemapNodes. Each node returns a o.a.c.c.sitemap.node.InvocationResult that indicates the execution state. This is one of NONE, PROCESSED, and COMPLETED: * NONE means that the node did not do any processing whatsoever (e.g. a MatchNode did not match). * PROCESSED means that the node did some processing, but the traversal should continue (e.g. the GenerateNode installed a Generator at the pipeline; but some other components might still be pending) * COMPLETED means that the node did some processing and the traversal should stop, since the invocation processing is completed (e.g. the PipelineNode executed the pipeline) Nodes that act as a switch (e.g. MatchNode, ErrorNode, etc.) aggregate the individual results of their children. So a MatchNode will respond with NONE if and only if all of its children return NONE, and with COMPLETED otherwise. EXECUTION CONTEXT ° When a pipeline and then further the sitemap is invoked, the execution context is passed. Since context has so many different meanings to us, we called this execution context o.a.c.c.sitemap.Invocation. It contains input parameters, sitemap parameters and a component provider and gives access to the result. Since the sitemap should be useable in any environment, the Invocation doesn't have any environment specific dependencies (e.g. the Servlet API). Hence, the input parameters are a general map. However, our idea is that environment specific parameters (e.g. the HTTPRequest) can be put into this map too and can be made accessible by an accessor helper class. So if a component needs access to environment specific parameters e.g. the HTTPRequest, it uses the appropriate accessor helper class. All components and accessor helper classes that belong to a certain environment (iow. are not generally available) should be bundled together. This creates a core module that is useable in any environment and additional modules for specific purposes. Since the sitemap shouldn't depend on a specific component container, the o.a.c.c.sitemap.ComponentProvider as an abstraction for specific containers, was introduced. So far we have implemented a o.a.c.c.sitemap.SpringComponentProvider that
[jira] Closed: (COCOON-2180) Corona - A proposal for a reimplementation
[ https://issues.apache.org/jira/browse/COCOON-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz closed COCOON-2180. -- Resolution: Fixed Imported into the whiteboard: https://svn.apache.org/repos/asf/cocoon/whiteboard/corona/ Corona - A proposal for a reimplementation -- Key: COCOON-2180 URL: https://issues.apache.org/jira/browse/COCOON-2180 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Steven Dolg Assignee: Reinhard Poetz Attachments: corona.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2173) AbstractCachingProcessingPipeline: Two requests can deadlock each other
[
https://issues.apache.org/jira/browse/COCOON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Daniel updated COCOON-2173:
-
Attachment: patchFor2.1.11.txt
For applying the patch to Cocoon 2.1.11 use patch -p6
$DownloadFolder/patchFor2.1.11.txt
I considered three possibilities to fix this issue
(1) using a timed wait
(2) removing the synchronization of requests with pipe locks completely
(3) redesign of the synchronization of requests
I chose (1) for simplicity. The current waitForLock implementation returns true
when the lock is the current thread (request for 2.1-dev and 2.2-dev). For the
calling method validatePipeline this means that there was no cached response
found. When there is a timeout on the timed wait it behaves the same way. The
default timeout is 250ms but it can be configured with the
timeoutForSynchronizingRequests parameter.
Unit tests for the new method timedWait are included in patchFor2.1.11.txt
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-dev (Current SVN)
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]
[continuum] BUILD FAILURE: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=68033projectId=51 Build statistics: State: Failed Previous State: Error Started at: Fri 21 Mar 2008 10:26:13 -0700 Finished at: Fri 21 Mar 2008 10:26:53 -0700 Total time: 39s Build Trigger: Schedule Build Number: 191 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: true Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 0 Failures: 0 Total time: 0 Output: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/6/cocoon-6.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon Version: 6 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-tools-modules:pom:5-SNAPSHOT for project null:cocoon-tools-modules:pom:5-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon for project: null:cocoon-tools-modules:pom:5-SNAPSHOT for project null:cocoon-tools-modules:pom:5-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1261) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:747) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:527) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.cocoon:cocoon' not found in repository: Unable to download the artifact from any repository org.apache.cocoon:cocoon:pom:6 from the specified remote repositories: central (http://repo1.maven.org/maven2) for
[jira] Updated: (COCOON-2173) AbstractCachingProcessingPipeline: Two requests can deadlock each other
[
https://issues.apache.org/jira/browse/COCOON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Daniel updated COCOON-2173:
-
Other Info: [Patch available]
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-dev (Current SVN)
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]
(/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]
(/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
Re: ForrestBot build for cocoon-docs FAILED
On Fri, 2008-03-21 at 17:11 +0100, Grzegorz Kossakowski wrote: Thorsten Scherler pisze: On Thu, 2008-03-20 at 12:34 +, [EMAIL PROTECTED] wrote: ... [java] X [0] 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html BROKEN: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy (Is a directory) ... [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs [echo] Oops, something broke Seems that the 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html file does not exist anymore. Did somebody moved it, or deleted it? It's located at: 2.1/userdocs/profile-generator.html Yeah, but it is linked to 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html I am not subscribed to your docu commit list so I am not sure when this got changed. for at least two years[1] now so I suppose it's something broken at your side. Forrest is building your docu on our zone with a bot. David and Ross know best but David is away and ask for a helping hand. http://markmail.org/message/5emz5c7czub5vwjh However as far as I understand it the source is taken from daisy and the link you posted is not taken into account since Daisy is the underlying source. The forrestbot reported on our zones server: broken-links link message=/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plug in.input.Daisy (Is a directory) uri=2.1/userdocs/sitemap-components/generators /optional/profile-generator.html referrer uri=2.1/userdocs/concepts/profiler.html/ /link /broken-links However I can find http://cocoon.zones.apache.org/daisy/legacydocs/documentation/userdocs/sitemap-components/generators/optional/profile-generator.html Not sure whether that is the right location or not, will keep on looking. salu2 [1] http://svn.apache.org/viewvc/cocoon/site/site/2.1/userdocs/profile-generator.html?view=log -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: ForrestBot build for cocoon-docs FAILED
On Fri, 2008-03-21 at 19:10 +0100, Thorsten Scherler wrote: On Fri, 2008-03-21 at 17:11 +0100, Grzegorz Kossakowski wrote: Thorsten Scherler pisze: On Thu, 2008-03-20 at 12:34 +, [EMAIL PROTECTED] wrote: ... [java] X [0] 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html BROKEN: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy (Is a directory) ... Not sure whether that is the right location or not, will keep on looking. I did but could not found anything, maybe Ross has an idea. Alternatively I can disable the forrestbot for now. Just drop me a mail and I will disable it. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: ForrestBot build for cocoon-docs FAILED
Thorsten Scherler pisze: On Fri, 2008-03-21 at 19:10 +0100, Thorsten Scherler wrote: On Fri, 2008-03-21 at 17:11 +0100, Grzegorz Kossakowski wrote: Thorsten Scherler pisze: On Thu, 2008-03-20 at 12:34 +, [EMAIL PROTECTED] wrote: ... [java] X [0] 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html BROKEN: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy (Is a directory) ... Not sure whether that is the right location or not, will keep on looking. I did but could not found anything, maybe Ross has an idea. Alternatively I can disable the forrestbot for now. Just drop me a mail and I will disable it. Hi Thorsten, I recalled that Ross has been pointing us many times to this[1] document that describes whole system very nicely. This way I managed to understand how it works and why it fails. It was due to broken link in a profiler a Cocoon Profiler[2] document that had a link to Profile generator document which was broken (see report[3]). I hope I fixed this problem and Forrestbot do its job just fine. [1] http://wiki.apache.org/cocoon/CocoonWebsiteUpdate [2] http://cocoon.zones.apache.org/daisy/legacydocs/documentation/userdocs/concepts/profiler.html [3] http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml -- Grzegorz
Re: ForrestBot build for cocoon-docs FAILED
On Sat, 2008-03-22 at 00:56 +0100, Grzegorz Kossakowski wrote: Thorsten Scherler pisze: On Fri, 2008-03-21 at 19:10 +0100, Thorsten Scherler wrote: On Fri, 2008-03-21 at 17:11 +0100, Grzegorz Kossakowski wrote: Thorsten Scherler pisze: On Thu, 2008-03-20 at 12:34 +, [EMAIL PROTECTED] wrote: ... [java] X [0] 2.1/userdocs/sitemap-components/generators/optional/profile-generator.html BROKEN: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy (Is a directory) ... Not sure whether that is the right location or not, will keep on looking. I did but could not found anything, maybe Ross has an idea. Alternatively I can disable the forrestbot for now. Just drop me a mail and I will disable it. Hi Thorsten, I recalled that Ross has been pointing us many times to this[1] document that describes whole system very nicely. This way I managed to understand how it works and why it fails. It was due to broken link in a profiler a Cocoon Profiler[2] document that had a link to Profile generator document which was broken (see report[3]). I hope I fixed this problem and Forrestbot do its job just fine. [1] http://wiki.apache.org/cocoon/CocoonWebsiteUpdate [2] http://cocoon.zones.apache.org/daisy/legacydocs/documentation/userdocs/concepts/profiler.html [3] http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml Yeah, perfect. Thanks Grzegorz. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
