From dev-return-95032-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Fri Jun 01 09:48:39 2007
Return-Path:
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 72315 invoked from network); 1 Jun 2007 09:48:38 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 1 Jun 2007 09:48:38 -0000
Received: (qmail 47180 invoked by uid 500); 1 Jun 2007 08:48:41 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 47116 invoked by uid 500); 1 Jun 2007 08:48:40 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
List-Post:
Reply-To: dev@cocoon.apache.org
List-Id:
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 47104 invoked by uid 99); 1 Jun 2007 08:48:40 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 01:48:40 -0700
X-ASF-Spam-Status: No, hits=-100.0 required=10.0
tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 01:48:36 -0700
Received: from brutus (localhost [127.0.0.1])
by brutus.apache.org (Postfix) with ESMTP id E4200714184
for ; Fri, 1 Jun 2007 01:48:15 -0700 (PDT)
Message-ID: <6401455.1180687695931.JavaMail.jira@brutus>
Date: Fri, 1 Jun 2007 01:48:15 -0700 (PDT)
From: "Carsten Ziegeler (JIRA)"
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-2071) Option to turn off pooling for
components (probably faster on new JVMs and simpler debugging)
In-Reply-To: <18349579.1180603215640.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
[ 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
>
>
> 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.