Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4847E68B.5040000@triplemind.com>
Date: Thu, 05 Jun 2008 15:13:47 +0200
From: Imran Pariyani <ipariyani@triplemind.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060909)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: multithreaded Content Aggregator migration from 2.1 to 2.2
References: <484557C5.8090506@triplemind.com>
 <484718F6.8030707@triplemind.com> <48471D1F.1070501@tuffmail.com>
In-Reply-To: <48471D1F.1070501@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hello Grzegorz,

Thanks for the reply .. and for the clue .. i guess i was looking in the 
wrong direction ... i will try and look into the source and also post 
the same to dev at cocoon .. if u find anything else on this issue 
please do let me know .. we cant upgrade till we solve this issue .. its 
quite crucial ..


Grzegorz Kossakowski wrote:
> Imran Pariyani pisze:
>> Hi
>
> Hi Imran,
>
>> last night i wasted 5 hrs overs this without any success .. i guess 
>> it has something to do with passing the RequestContextListener to the 
>> spring context .. i have initialized the listener in my web.xml and 
>> also added the config in applicationcontext.xml .. i checked 
>> everything on my end .. everything seems to be fine .. is something 
>> wrong with the cachemanager present in cocoon ?
>>
>> any help will be greatly appreciated !! ..
>
> Unfortunately, it looks like you stumbled across rather complicated 
> (and obscure) bug. It's related to the fact how Spring's request scope 
> works (objects are tied to the thread). If you run multithreaded 
> aggregation then child threads don't have an access to beans defined 
> with 'request' scope because they are visible only in parent thread.
>
> More details below...
>
> <snip/>
>
>>> org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:382) 
>>
>
> The failing code is:
>             if (touchedOM) {
>                 //Because of complicated flow of this source it must 
> maintain the cleaness of OM on its own
>                 ObjectModel newObjectModel;
>                 try {
>                     newObjectModel = 
> (ObjectModel)manager.lookup(ObjectModel.ROLE);
>                 } catch (ServiceException e) {
>                     throw new SAXException("Couldn't look up Object 
> Model", e);
>                 }
>                 newObjectModel.cleanupLocalContext();
>                 touchedOM = false;
>             }
> Here, manager.lookup fails because ObjectModel is a bean with request 
> scope.
>
> To be honest, I don't have an idea how this should be fixed. I guess 
> it's a bug of CocoonRunnable class but I don't know how to give child 
> threads access to parent thread variables in a safe way.
>
> This would require more investigation that I have no time for at the 
> moment, unfortunately.
>
> I hope it helped you a little to understand the problem. Maybe you 
> will find someone on dev@ mailing list that has an idea how to fix it.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org