[
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500580
]
Carsten Ziegeler commented on COCOON-2071:
------------------------------------------
I like the idea, but there is an issue with your patch: the current pooling
implementation does actually two things, a) pooling (obviously) and b) it
allows to use pooled components inside thread safe components by using the
proxy. The proxy ensures that each thread gets a different component for the
pooled component. Without this proxy all threads share the same instance which
will not work. (Btw, this is no issue for sitemap components as they are looked
up on demand). So we need this proxy.
I think it would be great if I could turn on/off pooling on a per component
base (just for fine-tuning), too. Additing an additional attribute to the
configuration and evaluating it should be fairly easy.
WDYT?
> 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.
