Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: 
 <1E0CC447E59C974CA5C7160D2A2854EC097D8F@SJMEMXMB04.stjude.sjcrh.local>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: <dev@cocoon.apache.org>
Date: Tue, 3 Feb 2004 15:42:01 -0600
Subject: RE: Are flowscript functions reentrant?
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-SEF-723560E2-3392-41F8-A983-A3F5486E94A: 1
content-class: urn:content-classes:message
Thread-Topic: Are flowscript functions reentrant?
Thread-Index: AcPpzbZ1ZquqxqX7RmmIbg6Vqt0NgQAo5iswAApjdlA=
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Hunsberger, Peter wrote:
 =20
> I've traced this down to a single generator that is not=20
> behaving in a reentrant fashion.  The generator simply calls=20
> an EJB then walks a resulting collection to spit out a (long)=20
> linear list of results. The request data is different going=20
> into the generator but the EJB data is the same coming back.=20
> A cursory inspection shows no obvious reason why; the code=20
> sets a couple of instance variables and then goes off and=20
> calls the EJB.=20
>=20
> Anyone know if it is possible that when a generator is pulled=20
> from a pool that the one passed back to handle the generate=20
> method might not be the same one as called for the setup=20
> method?  So far there seems like a vague possibility that=20
> could introduce this behavior though, if so, it's a little convoluted?

Just to close this off, it's our bug after all.  Hidden deep under many
layers of code one of our classes was stashing the request parameters in
another data class that was cached internally in a static HashMap.  The
window of opportunity was small, but it was possible for two generators
to hit the same single instance of this cached data; this pipeline had
many generators being aggregated in it, by the time all the setup's got
called for the second pass through the pipeline the first passes
generate methods could be at a point where it got clobbered:

    setup       generate
A -----------> ---------->
       B ---------> -----------> =20

If the setup sequence in B overlapped the generate sequence of A we got
our reentrancy problem.

I'm off to write a couple of clone methods.....