[wildfly-dev] Rework of Widlfly ThreadLocals

Eduardo Sant´Ana da Silva eduardo.santanadasilva at gmail.com
Thu Sep 19 13:28:34 EDT 2013


Be careful with thread pools  that can cause memory leaks . I had some
problems with that with tomcat, specially regarding HttpRequests.


I think that "at most one thread local per subsystem"  would be nice, since
each subsystem would be responsible to take care of what is on your context.


2013/9/19 Eduardo Martins <emartins at redhat.com>

> During the recent work wrt JSR 236 aka EE Concurrency I become aware that
> there is room for enhancing management of thread locals, which support
> setup and retrieval of invocation context within Wildfly, so I volunteer to
> do such task. Besides removing duplicated data (and the effort to manage
> it), this would make it much easier for the different models we currently
> support, for instance interceptors and web setup actions, to do their jobs.
>
> My idea is to centralise all in a single thread local for the whole
> Wildfly server, which then would contain entries for each subsystem and
> perhaps the MSC service container (removing the need for the static
> CurrentServiceContainer), or at most one thread local per subsystem. From
> this then I would start modelling each subsystem context from existing
> thread locals.
>
> Thoughts?
>
> --E
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
______________________
Eduardo Sant'Ana da Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130919/c34b8ca9/attachment.html 


More information about the wildfly-dev mailing list