cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler (JIRA)" <>
Subject [jira] Commented: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
Date Fri, 01 Jun 2007 10:19:16 GMT


Carsten Ziegeler commented on COCOON-2071:

Yes, the thread safe stuff is required for components that are marked as pooled but actually
are not pooled as well. Otherwise a thread safe components is using the same instance which
will result in problems. However there are use cases where the "environment" = (the component
using the poolable component) is aware that the component is pooled (or at least not thread
safe). This is the case in the pipeline/sitemap stuff. Therefore in these cases no proxy is

> Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
> ---------------------------------------------------------------------------------------------
>                 Key: COCOON-2071
>                 URL:
>             Project: Cocoon
>          Issue Type: Test
>          Components: - Components: Sitemap
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>            Priority: Minor
>         Attachments: disable-pooling-config.patch
> This is a patch that makes the pooling of components/beans optional: by setting this
in the applicationContext.xml
>   <!-- Activate Avalon Bridge -->
>   <avalon:bridge pooling="false"/>
> it is possible to turn off pooling completely. The idea is to start testing performance
differences between pooling and non-pooling. The default value for the "pooling" option is
true, so existing configurations without the attribute set will behave as before when this
patch is applied.
> Pooling was introduced back then when creating a new object in Java was slow and re-using
of existing objects was faster. Since Java 1.4 this is no longer the case, creating new objects
is said to be even faster than malloc() in C. Because pooling needs a recycle() method (to
reset internal stuff before reuse) and more calls, including some AOP and Proxy class stuff
to add pooling, it is worth to check what is faster nowadays.
> One thing that always annoys me during debugging is that the AOP stuff adds like 4-5
additional calls when accessing a pooled component in the stacktrace - code that you cannot
step into, because it has no java source. Removing pooling completely would make the Cocoon
architecture (especially the runtime architecture) much simpler.
> My idea is that Cocoon users can test the performance difference on their various systems
to get actual results. WDYT?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message