Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 86834 invoked from network); 11 Jun 2009 12:54:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Jun 2009 12:54:30 -0000 Received: (qmail 6937 invoked by uid 500); 11 Jun 2009 12:54:41 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 6836 invoked by uid 500); 11 Jun 2009 12:54:41 -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 6828 invoked by uid 99); 11 Jun 2009 12:54:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jun 2009 12:54:41 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [195.8.64.7] (HELO amenworld-outbound-smtp06.mail.eu.clara.net) (195.8.64.7) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jun 2009 12:54:30 +0000 Received: from atuileries-153-1-33-137.w83-202.abo.wanadoo.fr ([83.202.16.137]:54381 helo=neXtep) by relay06.mail.eu.clara.net (smtp-vh.amenworld.com [213.253.3.46]:11587) with esmtpa (authdaemon_login:cf1347@nextep-softwares.com) id 1MEjnF-0007k5-Ko (Exim 4.69) for dev@cocoon.apache.org (return-path ); Thu, 11 Jun 2009 13:54:09 +0100 Message-ID: <69FFE9E14BA04433B7039C5E6E7EFB38@neXtep> From: "Christophe Fondacci" To: Subject: IncludeTransformer bug when including external URL in parallel ? Date: Thu, 11 Jun 2009 14:54:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01C9EAA4.77A44440" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 Sender: cf1347@nextep-softwares.com X-Virus-Checked: Checked by ClamAV on apache.org Ce message est compos� et au format MIME. ------=_NextPart_000_00B3_01C9EAA4.77A44440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I work with Cocoon release 2.1.11. I got a working test XSP with 4 includes. The include transformer is defined to process inclusions in parallel. It works fine when i reference the inclusions through the sitemap via = "cocoon:/" URIs, I can see 4 threads processing the inclusions in = parallel. When I switch this to external URLs (via "http://"), everything works, = but inclusions are now serially processed. I digged and stepped into the Cocoon source and I can see that the = problem is located in the = org.apache.cocoon.transformation.IncludeTransformer line 563 (Cocoon = 2.1.11) :=20 synchronized (validity) { validity.addSource(source); } Each "external" inclusion after the first one is waiting for synch on = the addSource method call. When working with sitemap inclusions (cocoon://), the = source.getValidity() performed by the validity.addSource(...) method = returns immediately without really generating the element. There is no = synchronization issue here. The generation is done outside of this = synchronized block. When working with external URL inclusions (http://), the = source.getValidity(...) effectively PERFORMS the remote call and waits = for the element to be generated, thus creating synchronization issues = preventing the use of parallel inclusion of external URL. Each inclusion = will wait on the synchronize until the previous external call returns. I am working on ways to overload the MutliSourceValidity class to avoid = making the getValidity call under specific circumstances. Some questions now : - Is it a bug ? - Is there any workaround for this ? - Is it safe to extend the MutliSourceValidity class to avoid performing = the remote call in the addSource method ? Thank you very much for your time. I would be glad to give you some = details, should you need to. Christophe. ------=_NextPart_000_00B3_01C9EAA4.77A44440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
 
I work with Cocoon release = 2.1.11.
I got a working test XSP with 4=20 includes.
The include transformer is defined to = process=20 inclusions in parallel.
 
It works fine when i reference the = inclusions=20 through the sitemap via "cocoon:/" URIs, I can see 4 threads processing = the=20 inclusions in parallel.
When I switch this to external URLs = (via=20 "http://"), everything works, but inclusions are now serially=20 processed.
 
I digged and stepped into the Cocoon = source and I=20 can see that the problem is located in the=20 org.apache.cocoon.transformation.IncludeTransformer line 563 (Cocoon = 2.1.11) :=20
 
synchronized (validity)=20 {
    validity.addSource(source);
}

Each "external" = inclusion after=20 the first one is waiting for synch on the addSource method=20 call.

When working with sitemap = inclusions=20 (cocoon://), the source.getValidity() performed by the = validity.addSource(...)=20 method returns immediately without really generating the element. There = is no=20 synchronization issue here. The generation is done outside of this = synchronized=20 block.

When working with external = URL inclusions=20 (http://), the source.getValidity(...) effectively PERFORMS the = remote call=20 and waits for the element to be generated, thus creating synchronization = issues=20 preventing the use of parallel inclusion of external URL. Each inclusion = will=20 wait on the synchronize until the previous external call = returns.

I am working on ways to overload the MutliSourceValidity = class to=20 avoid making the getValidity call under specific circumstances.

Some questions now :

- Is it a bug ?

- Is there any workaround for this ?

- Is it safe to extend the MutliSourceValidity class to = avoid=20 performing the remote call in the addSource method ?

 

Thank you very much for your time. I would be glad to = give you=20 some details, should you need to.

Christophe.

------=_NextPart_000_00B3_01C9EAA4.77A44440--