Christopher Oliver <res1cf5x@verizon.net> 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?
|