On Mar 8, 2016, at 8:43 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: Hi guys, following request scope thread and to center the discussion on the thread safety part: do we work on this? Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. Questions: - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): <beans> <scopes> <thread> <active>JMS</active> <active>ASYNCHONOUS</active> </thread> </scopes> </beans> - start/stop API (this is typically an API the user should be able to control for its own threads) - CDI 2.*0*? wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

+1 I also use a own implementation of @ThreadScoped, but currently only via manual start/stop via: ThreadContext.start() or ThreadContext.stop(); If provide something, how will it act in a servlet environment? Will it share the same length as RequestScoped? Threads are reused by Tomcat AFAIR, so actually it would be longer as one request.

2016-03-08 14:53 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: > In Resin we added it precisely for these reasons and because it is very > useful for framework development as opposed to the Java SE thread local > API. We started it whenever a thread starts and destroyed it when the > thread ends just like thread local. It keeps things simple and consistent. > > On Mar 8, 2016, at 8:43 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; > wrote: > > Hi guys, > > following request scope thread and to center the discussion on the thread > safety part: do we work on this? > > Background: @RequestScoped is often used as a ThreadLocal instance > solution. A lot of SE or Batch implementations rely on it from what I saw > as well as async implementations reusing existing business logic with this > thread safety constraint. > > Proposal: providing a @ThreadScoped implementation is cheap for CDI and > implemenation and would avoid the headache we can have with @RequestScoped. > Will also remove the quite dark side of the spec regarding servlet request > and request scope since now we would have a more natural solution for all > of these situation so @RequestScoped goals wouldn't collide as much. > > Questions: > - is it automatically started as request scoped is (JMS, @Async, ...)? > Alternative could be some configuration in beans.xml (merged accross the > app): > > <beans> > <scopes> > <thread> > <active>JMS</active> > <active>ASYNCHONOUS</active> > </thread> > </scopes> > </beans> > > - start/stop API (this is typically an API the user should be able to > control for its own threads) > - CDI 2.*0*? > > wdyt? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: Hi guys, following request scope thread and to center the discussion on the thread safety part: do we work on this? Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. Questions: - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): <beans> <scopes> <thread> <active>JMS</active> <active>ASYNCHONOUS</active> </thread> </scopes> </beans> - start/stop API (this is typically an API the user should be able to control for its own threads) - CDI 2.*0*? wdyt? Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

From the servlet spec:

Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: Hi Mark, think 2.3.3.4 states the opposite. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: Back from JavaLand conference, so sorry for not kicking in earlier. I not quite get the argumentation chain. It’s that all triggered by async servlet requests? And isn’t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? LieGrue, strub > Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > > Hi guys, > > following request scope thread and to center the discussion on the thread safety part: do we work on this? > > Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. > > Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. > > Questions: > - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): > > <beans> > <scopes> > <thread> > <active>JMS</active> > <active>ASYNCHONOUS</active> > </thread> > </scopes> > </beans> > > - start/stop API (this is typically an API the user should be able to control for its own threads) > - CDI 2.*0*? > > wdyt? > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman(a)lycos.com&gt;: This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. > On Mar 11, 2016, at 6:01 AM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > E > From the servlet spec: > > „Java Enterprise Edition features such as Section 15.2.2, “Web Application Environment” on page 15-174 and Section 15.3.1, “Propagation of Security Identity in EJBTM Calls” on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.“ > > check „available only to threads executing the initial request“ > > Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. > > LieGrue, > strub > > >> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: >> >> Hi Mark, >> >> think 2.3.3.4 states the opposite. >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >> Back from JavaLand conference, so sorry for not kicking in earlier. >> >> I not quite get the argumentation chain. It’s that all triggered by async servlet requests? And isn’t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! >> >> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? >> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? >> >> LieGrue, >> strub >> >> >> >> >>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: >>> >>> Hi guys, >>> >>> following request scope thread and to center the discussion on the thread safety part: do we work on this? >>> >>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >>> >>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >>> >>> Questions: >>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >>> >>> <beans> >>> <scopes> >>> <thread> >>> <active>JMS</active> >>> <active>ASYNCHONOUS</active> >>> </thread> >>> </scopes> >>> </beans> >>> >>> - start/stop API (this is typically an API the user should be able to control for its own threads) >>> - CDI 2.*0*? >>> >>> wdyt? >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request.

I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. On Fr., 11. März 2016 at 17:17, Mark Struberg <struberg(a)yahoo.de <javascript:_e(%7B%7D,'cvml','struberg@yahoo.de');>> wrote: > Yes, but certain things in EE are assumed to be handled on a single > thread. And if you run on a servr then this is really not a blocker most > times. If I get many paralllel requests hitting my box then I do not need > async handling _that_ often. The whole overhead for setting up the new > thread, etc often heavily exceeds the benefits. > So I would not put too much energy into it… > > LieGrue, > strub > > > Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman(a)lycos.com > <javascript:_e(%7B%7D,'cvml','reza_rahman@lycos.com');>>: > > > > This is essentially in keeping with the minimalist nature of the EE > concurrency JSR. I believe most of it is left to vendors to do the right > thing for users. May be a good idea is this language can be tightened up. > > > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg <struberg(a)yahoo.de > <javascript:_e(%7B%7D,'cvml','struberg@yahoo.de');>> wrote: > >> E > >> From the servlet spec: > >> > >> „Java Enterprise Edition features such as Section 15.2.2, “Web > Application Environment” on page 15-174 and Section 15.3.1, “Propagation of > Security Identity in EJBTM Calls” on page 15-176 are available only to > threads executing the initial request or when the request is dispatched to > the container via the AsyncContext.dispatch method. Java Enterprise Edition > features may be available to other threads operating directly on the > response object via the AsyncContext.start(Runnable) method.“ > >> > >> check „available only to threads executing the initial request“ > >> > >> Also if you look at the servlet AsyncContext then all the wording is > written as MAY and not as MUST. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < > rmannibucau(a)gmail.com > <javascript:_e(%7B%7D,'cvml','rmannibucau@gmail.com');>>: > >>> > >>> Hi Mark, > >>> > >>> think 2.3.3.4 states the opposite. > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de > <javascript:_e(%7B%7D,'cvml','struberg@yahoo.de');>>: > >>> Back from JavaLand conference, so sorry for not kicking in earlier. > >>> > >>> I not quite get the argumentation chain. It’s that all triggered by > async servlet requests? And isn’t the servlet spec also saying that all the > request param etc may max be assigned to a single thread AT A TIME! > >>> > >>> Means that it might not be on multiple threads in parallel, but the > data is allowed to get moved from one thread to another (disapearing from > the first one), right? > >>> Would really need to dig into the wording of the async servlets spec > again, maybe has this in the back of his head? > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < > rmannibucau(a)gmail.com > <javascript:_e(%7B%7D,'cvml','rmannibucau@gmail.com');>>: > >>>> > >>>> Hi guys, > >>>> > >>>> following request scope thread and to center the discussion on the > thread safety part: do we work on this? > >>>> > >>>> Background: @RequestScoped is often used as a ThreadLocal instance > solution. A lot of SE or Batch implementations rely on it from what I saw > as well as async implementations reusing existing business logic with this > thread safety constraint. > >>>> > >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI > and implemenation and would avoid the headache we can have with > @RequestScoped. Will also remove the quite dark side of the spec regarding > servlet request and request scope since now we would have a more natural > solution for all of these situation so @RequestScoped goals wouldn't > collide as much. > >>>> > >>>> Questions: > >>>> - is it automatically started as request scoped is (JMS, @Async, > ...)? Alternative could be some configuration in beans.xml (merged accross > the app): > >>>> > >>>> <beans> > >>>> <scopes> > >>>> <thread> > >>>> <active>JMS</active> > >>>> <active>ASYNCHONOUS</active> > >>>> </thread> > >>>> </scopes> > >>>> </beans> > >>>> > >>>> - start/stop API (this is typically an API the user should be able > to control for its own threads) > >>>> - CDI 2.*0*? > >>>> > >>>> wdyt? > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev(a)lists.jboss.org > <javascript:_e(%7B%7D,'cvml','cdi-dev@lists.jboss.org');> > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>> > >>> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev(a)lists.jboss.org > <javascript:_e(%7B%7D,'cvml','cdi-dev@lists.jboss.org');> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org > <javascript:_e(%7B%7D,'cvml','cdi-dev@lists.jboss.org');> > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > <javascript:_e(%7B%7D,'cvml','cdi-dev@lists.jboss.org');> > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information.

Well as discussed in another mail, the concurrency spec is a bit ambiguous about context propagation, it's not explicitly forbidden. Would a new context also belong into the concurrency spec?

On Sa., 19. März 2016 at 21:57, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: > Hi, > > On Saturday, March 19, 2016, Stephan Knitelius <stephan(a)knitelius.com&gt; > wrote: > >> I would certainly agree with the assertion that in general it's not >> advisable to execute a request with multiple threads and that usually >> single threaded execution is sufficient. >> >> However I don't think ignoring it is an option. Concurrent operations >> can be launched even from CDI beans. Yet we don't properly support context >> propagation nor a context spanning all threads launched from a request. > > > That really sounds like a very useful proposal. Kinda like a session > scope, but for a select group of threads. > > Like so many other things, logically you'd say such thing should be > placed in the concurrency spec. Feels weird to put things in another less > logical place just because there are no plans do a concurrency spec update. > > Kind regards, > Arjan Tijms > > > >> >> I know that changing @requestScoped is probably out of the question, but >> at least we should consider adding a new context spanning all threads and >> defining a logical solution for context propagation that can be explained >> to the end user. >> >> >> >> On Fr., 11. März 2016 at 17:17, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> >>> Yes, but certain things in EE are assumed to be handled on a single >>> thread. And if you run on a servr then this is really not a blocker most >>> times. If I get many paralllel requests hitting my box then I do not need >>> async handling _that_ often. The whole overhead for setting up the new >>> thread, etc often heavily exceeds the benefits. >>> So I would not put too much energy into it… >>> >>> LieGrue, >>> strub >>> >>> > Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman(a)lycos.com&gt;: >>> > >>> > This is essentially in keeping with the minimalist nature of the EE >>> concurrency JSR. I believe most of it is left to vendors to do the right >>> thing for users. May be a good idea is this language can be tightened up. >>> > >>> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg <struberg(a)yahoo.de&gt; >>> wrote: >>> >> E >>> >> From the servlet spec: >>> >> >>> >> „Java Enterprise Edition features such as Section 15.2.2, “Web >>> Application Environment” on page 15-174 and Section 15.3.1, “Propagation of >>> Security Identity in EJBTM Calls” on page 15-176 are available only to >>> threads executing the initial request or when the request is dispatched to >>> the container via the AsyncContext.dispatch method. Java Enterprise Edition >>> features may be available to other threads operating directly on the >>> response object via the AsyncContext.start(Runnable) method.“ >>> >> >>> >> check „available only to threads executing the initial request“ >>> >> >>> >> Also if you look at the servlet AsyncContext then all the wording is >>> written as MAY and not as MUST. >>> >> >>> >> LieGrue, >>> >> strub >>> >> >>> >> >>> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < >>> rmannibucau(a)gmail.com&gt;: >>> >>> >>> >>> Hi Mark, >>> >>> >>> >>> think 2.3.3.4 states the opposite. >>> >>> >>> >>> >>> >>> Romain Manni-Bucau >>> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> >>> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >>> >>> Back from JavaLand conference, so sorry for not kicking in earlier. >>> >>> >>> >>> I not quite get the argumentation chain. It’s that all triggered by >>> async servlet requests? And isn’t the servlet spec also saying that all the >>> request param etc may max be assigned to a single thread AT A TIME! >>> >>> >>> >>> Means that it might not be on multiple threads in parallel, but the >>> data is allowed to get moved from one thread to another (disapearing from >>> the first one), right? >>> >>> Would really need to dig into the wording of the async servlets >>> spec again, maybe has this in the back of his head? >>> >>> >>> >>> LieGrue, >>> >>> strub >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < >>> rmannibucau(a)gmail.com&gt;: >>> >>>> >>> >>>> Hi guys, >>> >>>> >>> >>>> following request scope thread and to center the discussion on the >>> thread safety part: do we work on this? >>> >>>> >>> >>>> Background: @RequestScoped is often used as a ThreadLocal instance >>> solution. A lot of SE or Batch implementations rely on it from what I saw >>> as well as async implementations reusing existing business logic with this >>> thread safety constraint. >>> >>>> >>> >>>> Proposal: providing a @ThreadScoped implementation is cheap for >>> CDI and implemenation and would avoid the headache we can have with >>> @RequestScoped. Will also remove the quite dark side of the spec regarding >>> servlet request and request scope since now we would have a more natural >>> solution for all of these situation so @RequestScoped goals wouldn't >>> collide as much. >>> >>>> >>> >>>> Questions: >>> >>>> - is it automatically started as request scoped is (JMS, @Async, >>> ...)? Alternative could be some configuration in beans.xml (merged accross >>> the app): >>> >>>> >>> >>>> <beans> >>> >>>> <scopes> >>> >>>> <thread> >>> >>>> <active>JMS</active> >>> >>>> <active>ASYNCHONOUS</active> >>> >>>> </thread> >>> >>>> </scopes> >>> >>>> </beans> >>> >>>> >>> >>>> - start/stop API (this is typically an API the user should be able >>> to control for its own threads) >>> >>>> - CDI 2.*0*? >>> >>>> >>> >>>> wdyt? >>> >>>> >>> >>>> Romain Manni-Bucau >>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>>> _______________________________________________ >>> >>>> cdi-dev mailing list >>> >>>> cdi-dev(a)lists.jboss.org >>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>> >>> >>>> Note that for all code provided on this list, the provider >>> licenses the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> >>> >>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> cdi-dev mailing list >>> >> cdi-dev(a)lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> >>> >> Note that for all code provided on this list, the provider licenses >>> the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> > >>> > _______________________________________________ >>> > cdi-dev mailing list >>> > cdi-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/cdi-dev >>> > >>> > Note that for all code provided on this list, the provider licenses >>> the code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 ( >>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other >>> intellectual property rights inherent in such information. >> >>

On Mar 20, 2016, at 1:36 PM, Manfred Riem <mnriem(a)gmail.com&gt; wrote: Why is changing @RequestScoped out of the question? From my perspective when an AsyncContext is started the request is still there. It is just being served by a different thread. Certainly there is a need to work with the Servlet EG to figure out how to transfer “ownership” to the AsyncContext. Anyway my 2 cents Thanks! Kind regards, Manfred Riem > On Mar 19, 2016, at 3:35 PM, Stephan Knitelius <stephan(a)knitelius.com&gt; wrote: > > I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. > > However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. > > I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. > > > >> On Fr., 11. März 2016 at 17:17, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> Yes, but certain things in EE are assumed to be handled on a single thread. And if you run on a servr then this is really not a blocker most times. If I get many paralllel requests hitting my box then I do not need async handling _that_ often. The whole overhead for setting up the new thread, etc often heavily exceeds the benefits. >> So I would not put too much energy into it… >> >> LieGrue, >> strub >> >> > Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman(a)lycos.com&gt;: >> > >> > This is essentially in keeping with the minimalist nature of the EE concurrency JSR. I believe most of it is left to vendors to do the right thing for users. May be a good idea is this language can be tightened up. >> > >> >> On Mar 11, 2016, at 6:01 AM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> >> E >> >> From the servlet spec: >> >> >> >> „Java Enterprise Edition features such as Section 15.2.2, “Web Application Environment” on page 15-174 and Section 15.3.1, “Propagation of Security Identity in EJBTM Calls” on page 15-176 are available only to threads executing the initial request or when the request is dispatched to the container via the AsyncContext.dispatch method. Java Enterprise Edition features may be available to other threads operating directly on the response object via the AsyncContext.start(Runnable) method.“ >> >> >> >> check „available only to threads executing the initial request“ >> >> >> >> Also if you look at the servlet AsyncContext then all the wording is written as MAY and not as MUST. >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: >> >>> >> >>> Hi Mark, >> >>> >> >>> think 2.3.3.4 states the opposite. >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>> >> >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >> >>> Back from JavaLand conference, so sorry for not kicking in earlier. >> >>> >> >>> I not quite get the argumentation chain. It’s that all triggered by async servlet requests? And isn’t the servlet spec also saying that all the request param etc may max be assigned to a single thread AT A TIME! >> >>> >> >>> Means that it might not be on multiple threads in parallel, but the data is allowed to get moved from one thread to another (disapearing from the first one), right? >> >>> Would really need to dig into the wording of the async servlets spec again, maybe has this in the back of his head? >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> >>> >> >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: >> >>>> >> >>>> Hi guys, >> >>>> >> >>>> following request scope thread and to center the discussion on the thread safety part: do we work on this? >> >>>> >> >>>> Background: @RequestScoped is often used as a ThreadLocal instance solution. A lot of SE or Batch implementations rely on it from what I saw as well as async implementations reusing existing business logic with this thread safety constraint. >> >>>> >> >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI and implemenation and would avoid the headache we can have with @RequestScoped. Will also remove the quite dark side of the spec regarding servlet request and request scope since now we would have a more natural solution for all of these situation so @RequestScoped goals wouldn't collide as much. >> >>>> >> >>>> Questions: >> >>>> - is it automatically started as request scoped is (JMS, @Async, ...)? Alternative could be some configuration in beans.xml (merged accross the app): >> >>>> >> >>>> <beans> >> >>>> <scopes> >> >>>> <thread> >> >>>> <active>JMS</active> >> >>>> <active>ASYNCHONOUS</active> >> >>>> </thread> >> >>>> </scopes> >> >>>> </beans> >> >>>> >> >>>> - start/stop API (this is typically an API the user should be able to control for its own threads) >> >>>> - CDI 2.*0*? >> >>>> >> >>>> wdyt? >> >>>> >> >>>> Romain Manni-Bucau >> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >>>> _______________________________________________ >> >>>> cdi-dev mailing list >> >>>> cdi-dev(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>> >> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >>> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/cdi-dev >> > >> > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

A scope annotation cannot have a flag.

LieGrue, strub On Sunday, 20 March 2016, 20:25, Reza Rahman <reza_rahman(a)lycos.com&gt;

> > >As discussed elsewhere in this EG, even in the most pessimistic reading

> >On Mar 20, 2016, at 1:36 PM, Manfred Riem <mnriem(a)gmail.com&gt; wrote: > > >Why is changing @RequestScoped out of the question? >> >> >>From my perspective when an AsyncContext is started the request is

>> >> >>It is just being served by a different thread. >> >> >>Certainly there is a need to work with the Servlet EG to figure out how

>> >> >>Anyway my 2 cents >> >> >>Thanks! >> >> >>Kind regards, >>Manfred Riem >> >> >>On Mar 19, 2016, at 3:35 PM, Stephan Knitelius <stephan(a)knitelius.com&gt;

>>> >>>I would certainly agree with the assertion that in general it's not

>>> >>>However I don't think ignoring it is an option. Concurrent operations

>>> >>>I know that changing @requestScoped is probably out of the question,

>>> >>> >>> >>> >>>On Fr., 11. März 2016 at 17:17, Mark Struberg <struberg(a)yahoo.de&gt;

>>> >>>Yes, but certain things in EE are assumed to be handled on a single

>>>>So I would not put too much energy into it… >>>> >>>>LieGrue, >>>>strub >>>> >>>>> Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>> >>>>> This is essentially in keeping with the minimalist nature of the EE

>>>>> >>>>>> On Mar 11, 2016, at 6:01 AM, Mark Struberg <struberg(a)yahoo.de&gt;

>>>>>> E >>>>>> From the servlet spec: >>>>>> >>>>>> „Java Enterprise Edition features such as Section 15.2.2, “Web

>>>>>> >>>>>> check „available only to threads executing the initial request“ >>>>>> >>>>>> Also if you look at the servlet AsyncContext then all the wording

>>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau <

>>>>>>> >>>>>>> Hi Mark, >>>>>>> >>>>>>> think 2.3.3.4 states the opposite. >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> >>>>>>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >>>>>>> Back from JavaLand conference, so sorry for not kicking in

>>>>>>> >>>>>>> I not quite get the argumentation chain. It’s that all triggered

>>>>>>> >>>>>>> Means that it might not be on multiple threads in parallel, but

>>>>>>> Would really need to dig into the wording of the async servlets

>>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <

>>>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> following request scope thread and to center the discussion on

>>>>>>>> >>>>>>>> Background: @RequestScoped is often used as a ThreadLocal

>>>>>>>> >>>>>>>> Proposal: providing a @ThreadScoped implementation is cheap for

>>>>>>>> >>>>>>>> Questions: >>>>>>>> - is it automatically started as request scoped is (JMS, @Async,

>>>>>>>> >>>>>>>> <beans> >>>>>>>> <scopes> >>>>>>>> <thread> >>>>>>>> <active>JMS</active> >>>>>>>> <active>ASYNCHONOUS</active> >>>>>>>> </thread> >>>>>>>> </scopes> >>>>>>>> </beans> >>>>>>>> >>>>>>>> - start/stop API (this is typically an API the user should be

>>>>>>>> - CDI 2.*0*? >>>>>>>> >>>>>>>> wdyt? >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider

>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider

>>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses

>>>> >>>> >>>>_______________________________________________ >>>>cdi-dev mailing list &gt;&gt;&gt;&gt;cdi-dev(a)lists.jboss.org >>>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>>Note that for all code provided on this list, the provider licenses

_______________________________________________ >>>cdi-dev mailing list &gt;&gt;&gt;cdi-dev(a)lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>>Note that for all code provided on this list, the provider licenses

>> >_______________________________________________ >cdi-dev mailing list &gt;cdi-dev(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > >Note that for all code provided on this list, the provider licenses the

> > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the

Why is changing @RequestScoped out of the question? From my perspective when an AsyncContext is started the request is still there. It is just being served by a different thread.

Certainly there is a need to work with the Servlet EG to figure out how to transfer “ownership” to the AsyncContext. Anyway my 2 cents Thanks! Kind regards, Manfred Riem On Mar 19, 2016, at 3:35 PM, Stephan Knitelius <stephan(a)knitelius.com&gt; wrote: I would certainly agree with the assertion that in general it's not advisable to execute a request with multiple threads and that usually single threaded execution is sufficient. However I don't think ignoring it is an option. Concurrent operations can be launched even from CDI beans. Yet we don't properly support context propagation nor a context spanning all threads launched from a request. I know that changing @requestScoped is probably out of the question, but at least we should consider adding a new context spanning all threads and defining a logical solution for context propagation that can be explained to the end user. On Fr., 11. März 2016 at 17:17, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > Yes, but certain things in EE are assumed to be handled on a single > thread. And if you run on a servr then this is really not a blocker most > times. If I get many paralllel requests hitting my box then I do not need > async handling _that_ often. The whole overhead for setting up the new > thread, etc often heavily exceeds the benefits. > So I would not put too much energy into it… > > LieGrue, > strub > > > Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman(a)lycos.com&gt;: > > > > This is essentially in keeping with the minimalist nature of the EE > concurrency JSR. I believe most of it is left to vendors to do the right > thing for users. May be a good idea is this language can be tightened up. > > > >> On Mar 11, 2016, at 6:01 AM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > >> E > >> From the servlet spec: > >> > >> „Java Enterprise Edition features such as Section 15.2.2, “Web > Application Environment” on page 15-174 and Section 15.3.1, “Propagation of > Security Identity in EJBTM Calls” on page 15-176 are available only to > threads executing the initial request or when the request is dispatched to > the container via the AsyncContext.dispatch method. Java Enterprise Edition > features may be available to other threads operating directly on the > response object via the AsyncContext.start(Runnable) method.“ > >> > >> check „available only to threads executing the initial request“ > >> > >> Also if you look at the servlet AsyncContext then all the wording is > written as MAY and not as MUST. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 10.03.2016 um 19:52 schrieb Romain Manni-Bucau < > rmannibucau(a)gmail.com&gt;: > >>> > >>> Hi Mark, > >>> > >>> think 2.3.3.4 states the opposite. > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>> > >>> 2016-03-10 19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: > >>> Back from JavaLand conference, so sorry for not kicking in earlier. > >>> > >>> I not quite get the argumentation chain. It’s that all triggered by > async servlet requests? And isn’t the servlet spec also saying that all the > request param etc may max be assigned to a single thread AT A TIME! > >>> > >>> Means that it might not be on multiple threads in parallel, but the > data is allowed to get moved from one thread to another (disapearing from > the first one), right? > >>> Would really need to dig into the wording of the async servlets spec > again, maybe has this in the back of his head? > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > >>>> Am 08.03.2016 um 14:43 schrieb Romain Manni-Bucau < > rmannibucau(a)gmail.com&gt;: > >>>> > >>>> Hi guys, > >>>> > >>>> following request scope thread and to center the discussion on the > thread safety part: do we work on this? > >>>> > >>>> Background: @RequestScoped is often used as a ThreadLocal instance > solution. A lot of SE or Batch implementations rely on it from what I saw > as well as async implementations reusing existing business logic with this > thread safety constraint. > >>>> > >>>> Proposal: providing a @ThreadScoped implementation is cheap for CDI > and implemenation and would avoid the headache we can have with > @RequestScoped. Will also remove the quite dark side of the spec regarding > servlet request and request scope since now we would have a more natural > solution for all of these situation so @RequestScoped goals wouldn't > collide as much. > >>>> > >>>> Questions: > >>>> - is it automatically started as request scoped is (JMS, @Async, > ...)? Alternative could be some configuration in beans.xml (merged accross > the app): > >>>> > >>>> <beans> > >>>> <scopes> > >>>> <thread> > >>>> <active>JMS</active> > >>>> <active>ASYNCHONOUS</active> > >>>> </thread> > >>>> </scopes> > >>>> </beans> > >>>> > >>>> - start/stop API (this is typically an API the user should be able > to control for its own threads) > >>>> - CDI 2.*0*? > >>>> > >>>> wdyt? > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber > >>>> _______________________________________________ > >>>> cdi-dev mailing list > >>>> cdi-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>> > >>>> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > >>> > >>> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

I think the current spec wording already defines what happens in that case. At least there are TCK tests for it. LieGrue, strub On Sunday, 20 March 2016, 21:37, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: > >On Sun, Mar 20, 2016 at 6:36 PM, Manfred Riem <mnriem(a)gmail.com&gt; wrote: > >Why is changing @RequestScoped out of the question? >> >> >>From my perspective when an AsyncContext is started the request is still there. >> >> >>It is just being served by a different thread. > > >With just AsyncContext the original request thread can end and a new thread can write to the response. Both of them can access the request object after the AsyncContext has been handed to the second thread. But the second thread is not necessarily "connected" to anything, is it? It's just any random thread that gets the AsyncContext object passed in. > > > >Would it work here if there was a public CDI API available to activate the request scope (and session scope possibly) from a given instance of ServletRequest? > > >Regardless, this is a slightly different problem from when a given request thread submits work to a Concurrency spec executor. > > >Kind regards, >Arjan Tijms > >