Hi Thomas, thanks for pointing for a more precise answer ;-) This might come to the heart of Turbine ;-)
It started like this, that I thought it might be better to use a stream's method tryAdvance in TurbinePipeline.invokeNext (to begin with setting instead of valves.iterator valves.stream in TP.invoke call to state.set) - but this resulted into a endless loop/stackoverflow. After this using bulk stream/foreach would make ValveContext's invokeNext useless (or better it have to be removed ). Another question was: Is ThreadLocal of use here really? The mechanism of using a ThreadLocal<Iterator<Valve>> might be quite robust, although a valves stream seemed better. Could we not use a stream instead of CopyOnWriteArrayList for valves? But if valves are thread safe, do we need ThreadLocal at all? Is it worth the effort? Best regards, Georg P.S. We might need more testing to understand better, what's happening here? ;-) Von: Thomas Vandahl <[email protected]> An: Turbine Developers List <[email protected]> Datum: 08.03.2019 17:28 Betreff: Re: svn commit: r1854867 - in /turbine/core/trunk/src/java/org/apache/turbine/pipeline: DefaultSetEncodingValve.java DetermineActionValve.java DetermineTargetValve.java Valve.java ValveContext.java Hi Georg, On 06.03.19 14:15, Georg Kallidis wrote: > I'll let this for now. Changing the mechanism in TurbinePipeline > invokeNext method seems (to me) to be more complex, if we do not want to > remove ValveContext entirely ... might be more performant now than > otherwise without it. Would you care to explain what your initial intention was? Bye, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
