Christopher Oliver <[EMAIL PROTECTED]> writes: > >>>Unfortunately, the reentrancy problem is NOT fixed (sigh).... > >>> > >>> > >>> > >>> > >>What error do you get? > >> > >> > > > >Same as before; last request from a SendPage* into the pipeline > >clobbers the previous requests if they are running on the samepline. > > > >To recreate build a long running pipeline (we're returning > about 1,000 > >rows out of a possible 9,000,000 rows in our case) and call it twice > >with different request parameters that are supposed to > return different > >results: Eg; a generator that wraps request generator and > sleeps for > >30 seconds or so before returning. > > > > > The problem I fixed in 2.1.4-dev was with aggregating > multiple pipelines > that used <map:call function>. I don't know what's causing > the problem > in your case. If I have time I'll try to recreate and debug it.
We do use aggregation in the pipeline; a single pipeline is called from the flow script and aggregates the data from a bunch of generators, but I take it that, that is not this issue you where referring to? I've traced this down to a single generator that is not behaving in a reentrant fashion. The generator simply calls an EJB then walks a resulting collection to spit out a (long) linear list of results. The request data is different going into the generator but the EJB data is the same coming back. A cursory inspection shows no obvious reason why; the code sets a couple of instance variables and then goes off and calls the EJB. Anyone know if it is possible that when a generator is pulled from a pool that the one passed back to handle the generate method might not be the same one as called for the setup method? So far there seems like a vague possibility that could introduce this behavior though, if so, it's a little convoluted?
