[
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500623
]
Carsten Ziegeler commented on COCOON-2071:
------------------------------------------
Hmm, not sure if are speaking about the same thing here :)
One thing is the proxy which makes components marked as poolable thread safe.
This is a feature which should be turned on by default and we could think about
adding an additional configuration to not proxy these components (I think I did
this for the sitemap components, but I'm not sure if the code is still active).
The other thing is the pooling which if turned on, requires a proxy for
automatic lookup/release. Here it makes sense to have a global setting (on/off)
which should default to on (= pooling), and a per component configuration which
either turns on/off the pooling for a specific component. So you can set the
global switch to off and turn on pooling for some components or vice versa.
> Option to turn off pooling for components (probably faster on new JVMs and
> simpler debugging)
> ---------------------------------------------------------------------------------------------
>
> Key: COCOON-2071
> URL: https://issues.apache.org/jira/browse/COCOON-2071
> 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.
