headers
jira | 1 Jul 19:41
Picon
Favicon

[jira] Subscription: COCOON-open-with-patch

Issue Subscription
Filter: COCOON-open-with-patch (106 issues)
Subscriber: cocoon

Key         Summary
COCOON-2250 Wrong error message in Element.java (jx:element)
            https://issues.apache.org/jira/browse/COCOON-2250
COCOON-2249 XHTMLSerializer uses entity references " and ' which cause JavaScript parse errors
            https://issues.apache.org/jira/browse/COCOON-2249
COCOON-2246 HttpRequest  should handle encoding in getParameter and getParameterValues in the same way
            https://issues.apache.org/jira/browse/COCOON-2246
COCOON-2233 Update archetypes to current trunk artifact versions
            https://issues.apache.org/jira/browse/COCOON-2233
COCOON-2222 Add SaxParser configuration properties
            https://issues.apache.org/jira/browse/COCOON-2222
COCOON-2216 IncludeCacheManager can not perfom parallel includes
            https://issues.apache.org/jira/browse/COCOON-2216
COCOON-2212 jx:attribute does not check name is correct before proceeding
            https://issues.apache.org/jira/browse/COCOON-2212
COCOON-2197 Making the cocoon-auth-block acegi-security-sample work
            https://issues.apache.org/jira/browse/COCOON-2197
COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other
            https://issues.apache.org/jira/browse/COCOON-2173
COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page
            https://issues.apache.org/jira/browse/COCOON-2162
COCOON-2137 XSD Schemas for CForms Development
            https://issues.apache.org/jira/browse/COCOON-2137
COCOON-2114 fix sorting in TraversableGenerator
            https://issues.apache.org/jira/browse/COCOON-2114
COCOON-2108 xmodule:flow-attr Does not accept document objects
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Daniel | 3 Jul 10:22
Picon
Picon

[2.2] ThreadLocal use in PoolableProxyHandler

Does somebody know why ThreadLocal is used in PoolableProxyHandler [1]  
for the componentHolder in Cocoon 2.2?

Thanks, Alex

[1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java
Permalink | Reply | 5 comments |
headers
Carsten Ziegeler | 3 Jul 10:41
Picon
Favicon

Re: [2.2] ThreadLocal use in PoolableProxyHandler

Alexander Daniel wrote:
> Does somebody know why ThreadLocal is used in PoolableProxyHandler [1]
> for the componentHolder in Cocoon 2.2?
> 
Sure :)

Whenever components are taken out of the pool they need to be put back
somehow, so they are available for other clients again.
We use a thread local which is cleared when the request finishes,
so all used components get back into the pool.

Carsten

> Thanks, Alex
> 
> [1]
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java
> 
> 

--

-- 
Carsten Ziegeler
cziegeler <at> apache.org
Permalink | Reply | 4 comments |
headers
Alexander Daniel | 3 Jul 11:18
Picon
Picon

Re: [2.2] ThreadLocal use in PoolableProxyHandler

On 03.07.2009, at 10:41, Carsten Ziegeler wrote:

> Alexander Daniel wrote:
>> Does somebody know why ThreadLocal is used in PoolableProxyHandler  
>> [1]
>> for the componentHolder in Cocoon 2.2?
>>
> Sure :)
>
> Whenever components are taken out of the pool they need to be put back
> somehow, so they are available for other clients again.
> We use a thread local which is cleared when the request finishes,
> so all used components get back into the pool.

Thanks for the answer Carsten. What you describe is done by the  
destruction callback mechanism of Spring. But why can't we simply use  
a direct reference [2] to the component? Why is a ThreadLocal used as  
key to the component?

Alex

[2] private Object component = null;

>>
>> [1]
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java
>>
Permalink | Reply | 3 comments |
headers
Jukka Zitting | 3 Jul 12:17
Picon
Gravatar

Re: Cocoon interest to a Content Technology track in ACUS09?

Hi,

On Mon, Apr 27, 2009 at 10:59 AM, Jukka Zitting<jukka.zitting <at> gmail.com> wrote:
> I'm putting together a plan for a "Content Technology" track for the
> ApacheCon US 2009 in Oakland later this year.

I'm moving forward with this. Apart from Thorsten's proposal, are you
interested in organizing some Cocoon-related program at the ApacheCon?
The Content Technology track is already pretty crowded so I probably
can't promise you more than a single normal session with speaker
benefits (note that unlike before, speaker travel is not covered), but
we can also arrange space for unofficial sessions, workshops, meetups,
etc. To do this, I need people who'd like to help in planning and
organizing the Cocoon parts of the event. Any volunteers?

See the suggestions below and
http://wiki.apache.org/jackrabbit/ContentTrackApacheConUs2009 for more
information.

BR,

Jukka Zitting

SUGGESTIONS

* People pay to see the scheduled content at ApacheCon. Provide
material which will reach and attract our paying audience. If you have
Geeks for Geeks content to present, please save that for the daytime
un-con tracks, or evening MeetUps/BOFs. Consider that people attending
the main tracks probably need to have a clear business case for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carsten Ziegeler | 3 Jul 14:20
Picon
Favicon

Re: [2.2] ThreadLocal use in PoolableProxyHandler

Alexander Daniel wrote:
> On 03.07.2009, at 10:41, Carsten Ziegeler wrote:
> 
>> Alexander Daniel wrote:
>>> Does somebody know why ThreadLocal is used in PoolableProxyHandler [1]
>>> for the componentHolder in Cocoon 2.2?
>>>
>> Sure :)
>>
>> Whenever components are taken out of the pool they need to be put back
>> somehow, so they are available for other clients again.
>> We use a thread local which is cleared when the request finishes,
>> so all used components get back into the pool.
> 
> Thanks for the answer Carsten. What you describe is done by the
> destruction callback mechanism of Spring. But why can't we simply use a
> direct reference [2] to the component? Why is a ThreadLocal used as key
> to the component?
> 
Hmm, not sure if I understand you correctly.
The poolable factory returns a single instance to spring which is the
proxy - spring has no knowledge of poolable components.
Therefore the proxy together with a thread local is used to internally
forward the method calls to instances from the pool. There is a separate
instance per thread - otherwise you would run into multi-threading
issues as the same instance would be used across requests.

Carsten
--

-- 
Carsten Ziegeler
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexander Daniel | 3 Jul 16:31
Picon
Picon

Re: [2.2] ThreadLocal use in PoolableProxyHandler

On 03.07.2009, at 14:20, Carsten Ziegeler wrote:

> Alexander Daniel wrote:
>> On 03.07.2009, at 10:41, Carsten Ziegeler wrote:
>>
>>> Alexander Daniel wrote:
>>>> Does somebody know why ThreadLocal is used in  
>>>> PoolableProxyHandler [1]
>>>> for the componentHolder in Cocoon 2.2?
>>>>
>>> Sure :)
>>>
>>> Whenever components are taken out of the pool they need to be put  
>>> back
>>> somehow, so they are available for other clients again.
>>> We use a thread local which is cleared when the request finishes,
>>> so all used components get back into the pool.
>>
>> Thanks for the answer Carsten. What you describe is done by the
>> destruction callback mechanism of Spring. But why can't we simply  
>> use a
>> direct reference [2] to the component? Why is a ThreadLocal used as  
>> key
>> to the component?
>>
> Hmm, not sure if I understand you correctly.
> The poolable factory returns a single instance to spring which is the
> proxy - spring has no knowledge of poolable components.
> Therefore the proxy together with a thread local is used to internally
> forward the method calls to instances from the pool. There is a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Daniel (JIRA | 3 Jul 17:00
Picon
Favicon

[jira] Created: (COCOON-2259) Memory leak in PoolableProxyHandler

Memory leak in PoolableProxyHandler
-----------------------------------

                 Key: COCOON-2259
                 URL: https://issues.apache.org/jira/browse/COCOON-2259
             Project: Cocoon
          Issue Type: Bug
          Components: * Cocoon Core
    Affects Versions: 2.2, 2.2-dev (Current SVN)
            Reporter: Alexander Daniel

I reproduced the problem with following pipeline and by adding log output to PoolableProxyHandler [1]
<map:pipeline id="cocoonTest" type="noncaching">
	<map:match pattern="cocoonProtocol">
		<map:generate src="cocoon://sub"/>
		<map:serialize type="xhtml"/>
	</map:match>
	<map:match pattern="sub">
		<map:generate src="welcome/welcome.xml"/>
		<map:transform src="welcome/welcome.xslt"/>
		<map:serialize type="xhtml"/>
	</map:match>
</map:pipeline>

Changing the line 
     this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.handler.hashCode();
to
     this.attributeName = PoolableProxyHandler.class.getName() + '/' + this.hashCode();
fixes the memory leak.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Carsten Ziegeler | 3 Jul 17:08
Picon
Favicon

Re: [2.2] ThreadLocal use in PoolableProxyHandler

Alexander Daniel wrote
> 
> PoolableFactoryBean [2] creates a new PoolableProxyHandler instance [1]
> for each pooled component used in a pipeline, i.e. it will not be shared
> across different requests. Therefore I do not understand the use of
> ThreadLocal.
Yes, you're right for sitemap components - but this isn't true for any
other component. Imagine a singleton component using a poolable. The
singleton is used by multiple threads and therefore each thread
requires an own instance

Now, this is not optimal and actually it's legacy code - it is only used
for old Avalon components.

Carsten
> 
> Alex
> 
> [1]
>     public Object getObject() throws Exception {
>         return Proxy.newProxyInstance(this.getClass().getClassLoader(),
>                                       this.interfaces,
>                                       new PoolableProxyHandler(this));
>     }
> 
> [2]
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Continuum@vmbuild.apache.org | 3 Jul 17:45
Picon
Favicon

[continuum] BUILD SUCCESSFUL: Cocoon - Apache Cocoon [build root] -

Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=197454&projectId=51

Build statistics:
  State: Ok
  Previous State: Building
  Started at: Fri 3 Jul 2009 08:18:08 -0700
  Finished at: Fri 3 Jul 2009 08:41:50 -0700
  Total time: 23m 42s
  Build Trigger: Schedule
  Build Number: 363
  Exit code: 0
  Building machine hostname: vmbuild.apache.org
  Operating system : Linux(unknown)
  Java Home version : 
          java version "1.5.0_12"
          Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
          Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
        
  Builder version :
          Maven version: 2.0.9
          Java version: 1.5.0_12
          OS name: "linux" version: "2.6.24-23-server" arch: "i386" Family: "unix"
    
****************************************************************************
SCM Changes:
****************************************************************************
Changed: reinhard  <at>  Tue 16 Jun 2009 12:30:46 -0700
Comment: add release dates
Files changed:
  /cocoon/trunk/subprojects/cocoon-block-deployment/src/changes/changes.xml ( 785350 )
(Continue reading)

Permalink | Reply | 5 comments |

Gmane