You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Rohit Kelapure <ke...@gmail.com> on 2012/06/22 18:16:21 UTC
CDI context propagation for threads spawned asynchronously using
servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Team,
Do we have a standard way of propagating CDI contexts (request, session,
application, singleton, conversation) and other threadlocal state from a
parent thread say servicing a servlet request to its dispatched child
runnable using the servlet 3.0 AsyncContext.startAsync or the WorkManager
APIs.
I understand that the solution may be specific to individual containers
like Tomcat, WebLogic, WAS etc ...
Has anyone already solved this problem for their container ?
Thought I would ask before fixing it in WAS.
-cheers,
Rohit Kelapure
Re: CDI context propagation for threads spawned asynchronously using
servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Posted by Rohit Kelapure <ke...@gmail.com>.
Correct. Some code in the container peeks, pushes and pops this JavaEE
context before and after the work has been dispatched.
On Fri, Jun 22, 2012 at 12:24 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Hi,
>
> i don't know any standard way but what i often saw was to create a kind of
> "invocation context" to avoid to need anything in the async call.
>
> - Romain
>
>
> 2012/6/22 Rohit Kelapure <ke...@gmail.com>
>
> > Team,
> >
> > Do we have a standard way of propagating CDI contexts (request, session,
> > application, singleton, conversation) and other threadlocal state from a
> > parent thread say servicing a servlet request to its dispatched child
> > runnable using the servlet 3.0 AsyncContext.startAsync or the WorkManager
> > APIs.
> >
> > I understand that the solution may be specific to individual containers
> > like Tomcat, WebLogic, WAS etc ...
> > Has anyone already solved this problem for their container ?
> > Thought I would ask before fixing it in WAS.
> >
> > -cheers,
> > Rohit Kelapure
> >
>
Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Posted by Mark Struberg <st...@yahoo.de>.
As far as I understood, not really:
"..., and then exit from the container on the original thread."
Thus you start the new thread, pass over the context and then exit from the original thread. -> only 1 thread for CDI. It's basically a thread-swapping.
IF this gets done atomically (CDI-1.1 will cover async-supported) then it should work.
But certainly it will take some time to work out and implement. And a user needs a way to tell the container that his app is still not async-ready (pessimistic default).
LieGrue,
strub
>________________________________
> From: Rohit Kelapure <ke...@gmail.com>
>To: dev@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>Sent: Friday, June 22, 2012 11:33 PM
>Subject: Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
>
>
>Servlet 3.0 - Section 2.3.3.3.
>
>
>" When asyncSupported is set to true the application can start asynchronous processing in a separate thread by calling startAsync , passing it a reference to the request and response objects, and then exit from the container on the original thread. This means that the response will traverse (in reverse order) the same filters (or filter chain) that were traversed on the way in. The response isn't committed till complete is called on the AsyncContext.
>
>
>The application is responsible to handle concurrent access to the request and response objects if the async task is executing before the container-initiated dispatch that called startAsync has returned to the container. "
>
>
>This mean parent and async task/s may be executing concurrently.
>
>
>cheers,
>--Rohit
>
>
>
>On Fri, Jun 22, 2012 at 5:21 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>
>>
>>My understanding of this is that there is still only 1 concurrent Thread. The 'request' will will just get moved over to a new worker, but still max 1 at a time, isn't?
>>
>>But have only read over the spec quickly, will need to dig much deeper...
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>>________________________________
>>> From: Rohit Kelapure <ke...@gmail.com>
>>>To: dev@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>>>Sent: Friday, June 22, 2012 11:12 PM
>>
>>>Subject: Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
>>>
>>>
>>>
>>>Team,
>>>
>>>
>>>Does it make sense to propagate the RequestContext ? given that there may be multiple threads that will inherit and share the same RequestContext
>>>
>>>
>>>We will need to manage the destruction of the RequestContext such that only the last one (Parent + child async threads) ends the context.
>>>
>>>
>>>This could get messy with locking and keeping track of when each runnable exits. For servlet 3.0 this may not be a problem since the AsyncListener will abstract all this for us. Unfortunately there is no good place to add the per request listener asynclistener.
>>>
>>>
>>>The basic issue here is that sharing of the RequestContext leads to complexity in ending the context.
>>>
>>>
>>>-cheers,
>>>Rohit
>>>
>>>
>>>On Fri, Jun 22, 2012 at 12:36 PM, Mark Struberg <st...@yahoo.de> wrote:
>>>
>>>
>>>>
>>>>Hi folks!
>>>>
>>>>We are aware that OWB currently doesn't provide this. But all the information is already centrally collected and maintained in the ContextsService.
>>>>For WAS this will most probably be the WebContextsService. So all you need to know is centrally available there.
>>>>
>>>>Also the TheadLocal caches in the proxies will need to get cleared (if being used).
>>>>
>>>>In practice this doesn't make any problems atm, as asynchronous requests must only get performed if ALL involved Servlets, Filters, etc must have
>>>>
>>>><async-supported>true</async-supported>
>>>>
>>>>
>>>>Of course, at the end of the day we should support it!
>>>>
>>>>Will take a look once I'm back from the conference next week.
>>>>
>>>>
>>>>LieGrue,
>>>>strub
>>>>
>>>>
>>>>----- Original Message -----
>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>>>> To: dev@openwebbeans.apache.org
>>>>> Cc:
>>>>> Sent: Friday, June 22, 2012 6:24 PM
>>>>> Subject: Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
>>>>>
>>>>> Hi,
>>>>>
>>>>> i don't know any standard way but what i often saw was to create a kind of
>>>>> "invocation context" to avoid to need anything in the async call.
>>>>>
>>>>> - Romain
>>>>>
>>>>>
>>>>> 2012/6/22 Rohit Kelapure <ke...@gmail.com>
>>>>>
>>>>>> Team,
>>>>>>
>>>>>> Do we have a standard way of propagating CDI contexts (request, session,
>>>>>> application, singleton, conversation) and other threadlocal state from a
>>>>>> parent thread say servicing a servlet request to its dispatched child
>>>>>> runnable using the servlet 3.0 AsyncContext.startAsync or the WorkManager
>>>>>> APIs.
>>>>>>
>>>>>> I understand that the solution may be specific to individual containers
>>>>>> like Tomcat, WebLogic, WAS etc ...
>>>>>> Has anyone already solved this problem for their container ?
>>>>>> Thought I would ask before fixing it in WAS.
>>>>>>
>>>>>> -cheers,
>>>>>> Rohit Kelapure
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: CDI context propagation for threads spawned asynchronously using
servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Posted by Rohit Kelapure <ke...@gmail.com>.
Servlet 3.0 - Section 2.3.3.3.
" When asyncSupported is set to true the application can start
asynchronous processing in a separate thread by calling startAsync ,
passing it a reference to the request and response objects, and then exit
from the container on the original thread. This means that the response
will traverse (in reverse order) the same filters (or filter chain) that
were traversed on the way in. The response isn't committed till complete is
called on the AsyncContext.
*The application is responsible to handle concurrent access to the request
and response objects if the async task is executing before the
container-initiated dispatch that called startAsync has returned to the
container.* "
This mean parent and async task/s may be executing concurrently.
cheers,
--Rohit
On Fri, Jun 22, 2012 at 5:21 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>
> My understanding of this is that there is still only 1 concurrent Thread.
> The 'request' will will just get moved over to a new worker, but still max
> 1 at a time, isn't?
>
> But have only read over the spec quickly, will need to dig much deeper...
>
> LieGrue,
> strub
>
>
>
>
> >________________________________
> > From: Rohit Kelapure <ke...@gmail.com>
> >To: dev@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
> >Sent: Friday, June 22, 2012 11:12 PM
> >Subject: Re: CDI context propagation for threads spawned asynchronously
> using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
> >
> >
> >
> >Team,
> >
> >
> >Does it make sense to propagate the RequestContext ? given that there
> may be multiple threads that will inherit and share the same RequestContext
> >
> >
> >We will need to manage the destruction of the RequestContext such that
> only the last one (Parent + child async threads) ends the context.
> >
> >
> >This could get messy with locking and keeping track of when each runnable
> exits. For servlet 3.0 this may not be a problem since the AsyncListener
> will abstract all this for us. Unfortunately there is no good place to add
> the per request listener asynclistener.
> >
> >
> >The basic issue here is that sharing of the RequestContext leads to
> complexity in ending the context.
> >
> >
> >-cheers,
> >Rohit
> >
> >
> >On Fri, Jun 22, 2012 at 12:36 PM, Mark Struberg <st...@yahoo.de>
> wrote:
> >
> >
> >>
> >>Hi folks!
> >>
> >>We are aware that OWB currently doesn't provide this. But all the
> information is already centrally collected and maintained in the
> ContextsService.
> >>For WAS this will most probably be the WebContextsService. So all you
> need to know is centrally available there.
> >>
> >>Also the TheadLocal caches in the proxies will need to get cleared (if
> being used).
> >>
> >>In practice this doesn't make any problems atm, as asynchronous requests
> must only get performed if ALL involved Servlets, Filters, etc must have
> >>
> >><async-supported>true</async-supported>
> >>
> >>
> >>Of course, at the end of the day we should support it!
> >>
> >>Will take a look once I'm back from the conference next week.
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>----- Original Message -----
> >>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>> To: dev@openwebbeans.apache.org
> >>> Cc:
> >>> Sent: Friday, June 22, 2012 6:24 PM
> >>> Subject: Re: CDI context propagation for threads spawned
> asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager
> APIs
> >>>
> >>> Hi,
> >>>
> >>> i don't know any standard way but what i often saw was to create a
> kind of
> >>> "invocation context" to avoid to need anything in the async call.
> >>>
> >>> - Romain
> >>>
> >>>
> >>> 2012/6/22 Rohit Kelapure <ke...@gmail.com>
> >>>
> >>>> Team,
> >>>>
> >>>> Do we have a standard way of propagating CDI contexts (request,
> session,
> >>>> application, singleton, conversation) and other threadlocal state
> from a
> >>>> parent thread say servicing a servlet request to its dispatched child
> >>>> runnable using the servlet 3.0 AsyncContext.startAsync or the
> WorkManager
> >>>> APIs.
> >>>>
> >>>> I understand that the solution may be specific to individual
> containers
> >>>> like Tomcat, WebLogic, WAS etc ...
> >>>> Has anyone already solved this problem for their container ?
> >>>> Thought I would ask before fixing it in WAS.
> >>>>
> >>>> -cheers,
> >>>> Rohit Kelapure
> >>>>
> >>>
> >>
> >
> >
> >
>
Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Posted by Mark Struberg <st...@yahoo.de>.
My understanding of this is that there is still only 1 concurrent Thread. The 'request' will will just get moved over to a new worker, but still max 1 at a time, isn't?
But have only read over the spec quickly, will need to dig much deeper...
LieGrue,
strub
>________________________________
> From: Rohit Kelapure <ke...@gmail.com>
>To: dev@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>Sent: Friday, June 22, 2012 11:12 PM
>Subject: Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
>
>
>
>Team,
>
>
>Does it make sense to propagate the RequestContext ? given that there may be multiple threads that will inherit and share the same RequestContext
>
>
>We will need to manage the destruction of the RequestContext such that only the last one (Parent + child async threads) ends the context.
>
>
>This could get messy with locking and keeping track of when each runnable exits. For servlet 3.0 this may not be a problem since the AsyncListener will abstract all this for us. Unfortunately there is no good place to add the per request listener asynclistener.
>
>
>The basic issue here is that sharing of the RequestContext leads to complexity in ending the context.
>
>
>-cheers,
>Rohit
>
>
>On Fri, Jun 22, 2012 at 12:36 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>
>>
>>Hi folks!
>>
>>We are aware that OWB currently doesn't provide this. But all the information is already centrally collected and maintained in the ContextsService.
>>For WAS this will most probably be the WebContextsService. So all you need to know is centrally available there.
>>
>>Also the TheadLocal caches in the proxies will need to get cleared (if being used).
>>
>>In practice this doesn't make any problems atm, as asynchronous requests must only get performed if ALL involved Servlets, Filters, etc must have
>>
>><async-supported>true</async-supported>
>>
>>
>>Of course, at the end of the day we should support it!
>>
>>Will take a look once I'm back from the conference next week.
>>
>>
>>LieGrue,
>>strub
>>
>>
>>----- Original Message -----
>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>> To: dev@openwebbeans.apache.org
>>> Cc:
>>> Sent: Friday, June 22, 2012 6:24 PM
>>> Subject: Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
>>>
>>> Hi,
>>>
>>> i don't know any standard way but what i often saw was to create a kind of
>>> "invocation context" to avoid to need anything in the async call.
>>>
>>> - Romain
>>>
>>>
>>> 2012/6/22 Rohit Kelapure <ke...@gmail.com>
>>>
>>>> Team,
>>>>
>>>> Do we have a standard way of propagating CDI contexts (request, session,
>>>> application, singleton, conversation) and other threadlocal state from a
>>>> parent thread say servicing a servlet request to its dispatched child
>>>> runnable using the servlet 3.0 AsyncContext.startAsync or the WorkManager
>>>> APIs.
>>>>
>>>> I understand that the solution may be specific to individual containers
>>>> like Tomcat, WebLogic, WAS etc ...
>>>> Has anyone already solved this problem for their container ?
>>>> Thought I would ask before fixing it in WAS.
>>>>
>>>> -cheers,
>>>> Rohit Kelapure
>>>>
>>>
>>
>
>
>
Re: CDI context propagation for threads spawned asynchronously using
servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Posted by Rohit Kelapure <ke...@gmail.com>.
Team,
Does it make sense to propagate the RequestContext ? given that there may
be multiple threads that will inherit and share the same RequestContext
We will need to manage the destruction of the RequestContext such that only
the last one (Parent + child async threads) ends the context.
This could get messy with locking and keeping track of when each runnable
exits. For servlet 3.0 this may not be a problem since the AsyncListener
will abstract all this for us. Unfortunately there is no good place to add
the per request listener asynclistener.
The basic issue here is that sharing of the RequestContext leads to
complexity in ending the context.
-cheers,
Rohit
On Fri, Jun 22, 2012 at 12:36 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>
> Hi folks!
>
> We are aware that OWB currently doesn't provide this. But all the
> information is already centrally collected and maintained in the
> ContextsService.
> For WAS this will most probably be the WebContextsService. So all you need
> to know is centrally available there.
>
> Also the TheadLocal caches in the proxies will need to get cleared (if
> being used).
>
> In practice this doesn't make any problems atm, as asynchronous requests
> must only get performed if ALL involved Servlets, Filters, etc must have
>
> <async-supported>true</async-supported>
>
>
> Of course, at the end of the day we should support it!
>
> Will take a look once I'm back from the conference next week.
>
>
> LieGrue,
> strub
>
> ----- Original Message -----
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > To: dev@openwebbeans.apache.org
> > Cc:
> > Sent: Friday, June 22, 2012 6:24 PM
> > Subject: Re: CDI context propagation for threads spawned asynchronously
> using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
> >
> > Hi,
> >
> > i don't know any standard way but what i often saw was to create a kind
> of
> > "invocation context" to avoid to need anything in the async call.
> >
> > - Romain
> >
> >
> > 2012/6/22 Rohit Kelapure <ke...@gmail.com>
> >
> >> Team,
> >>
> >> Do we have a standard way of propagating CDI contexts (request,
> session,
> >> application, singleton, conversation) and other threadlocal state from
> a
> >> parent thread say servicing a servlet request to its dispatched child
> >> runnable using the servlet 3.0 AsyncContext.startAsync or the
> WorkManager
> >> APIs.
> >>
> >> I understand that the solution may be specific to individual containers
> >> like Tomcat, WebLogic, WAS etc ...
> >> Has anyone already solved this problem for their container ?
> >> Thought I would ask before fixing it in WAS.
> >>
> >> -cheers,
> >> Rohit Kelapure
> >>
> >
>
Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Posted by Mark Struberg <st...@yahoo.de>.
Hi folks!
We are aware that OWB currently doesn't provide this. But all the information is already centrally collected and maintained in the ContextsService.
For WAS this will most probably be the WebContextsService. So all you need to know is centrally available there.
Also the TheadLocal caches in the proxies will need to get cleared (if being used).
In practice this doesn't make any problems atm, as asynchronous requests must only get performed if ALL involved Servlets, Filters, etc must have
<async-supported>true</async-supported>
Of course, at the end of the day we should support it!
Will take a look once I'm back from the conference next week.
LieGrue,
strub
----- Original Message -----
> From: Romain Manni-Bucau <rm...@gmail.com>
> To: dev@openwebbeans.apache.org
> Cc:
> Sent: Friday, June 22, 2012 6:24 PM
> Subject: Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs
>
> Hi,
>
> i don't know any standard way but what i often saw was to create a kind of
> "invocation context" to avoid to need anything in the async call.
>
> - Romain
>
>
> 2012/6/22 Rohit Kelapure <ke...@gmail.com>
>
>> Team,
>>
>> Do we have a standard way of propagating CDI contexts (request, session,
>> application, singleton, conversation) and other threadlocal state from a
>> parent thread say servicing a servlet request to its dispatched child
>> runnable using the servlet 3.0 AsyncContext.startAsync or the WorkManager
>> APIs.
>>
>> I understand that the solution may be specific to individual containers
>> like Tomcat, WebLogic, WAS etc ...
>> Has anyone already solved this problem for their container ?
>> Thought I would ask before fixing it in WAS.
>>
>> -cheers,
>> Rohit Kelapure
>>
>
Re: CDI context propagation for threads spawned asynchronously using
servlet 3.0 and javax.resource.spi.work.WorkManager APIs
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
i don't know any standard way but what i often saw was to create a kind of
"invocation context" to avoid to need anything in the async call.
- Romain
2012/6/22 Rohit Kelapure <ke...@gmail.com>
> Team,
>
> Do we have a standard way of propagating CDI contexts (request, session,
> application, singleton, conversation) and other threadlocal state from a
> parent thread say servicing a servlet request to its dispatched child
> runnable using the servlet 3.0 AsyncContext.startAsync or the WorkManager
> APIs.
>
> I understand that the solution may be specific to individual containers
> like Tomcat, WebLogic, WAS etc ...
> Has anyone already solved this problem for their container ?
> Thought I would ask before fixing it in WAS.
>
> -cheers,
> Rohit Kelapure
>