You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2015/06/12 09:25:33 UTC
stateless pool eviction and threads
Hi guys,
already got this issue and Mark pinged me about it yesterday. ATM we have 1
eviction thread by stateless instance manager (pool). So if you have 100
stateless beans you then have 100 threads doing nothing.
Do we want to reduce it to N fixed threads (default to 3 maybe?) per
stateless container (but multiple tasks to keep access timeout and close
timeout respected)?
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>
Re: stateless pool eviction and threads
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Probably worth it waiting to hear from David.
I know he spent some significant time re architecting the stateless pool.
There were probably some reasons we may not know.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Fri, Jun 12, 2015 at 9:10 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le 12 juin 2015 20:55, "Adam Cornett" <ad...@gmail.com> a écrit :
> >
> > Would it make sense to have the pool size scale up automatically with the
> > stateless bean count at an adjustable ratio and a hard floor of 3 or so
> > threads?
>
> Hmm maybe i get it wrong but the idea is to prevent it to scale/increase
> thread count
>
> > On Jun 12, 2015 2:45 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> >
> > > +1 Think that makes it also easier to debug and maintain. The current
> > > approach simply doesn’t scale well in big deployments.
> > >
>
> Well it does but thread dumps are a pain and it is useless
>
> > > LieGrue,
> > > strub
> > >
> > >
> > > > Am 12.06.2015 um 09:25 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> > > >:
> > > >
> > > > Hi guys,
> > > >
> > > > already got this issue and Mark pinged me about it yesterday. ATM we
> > > have 1
> > > > eviction thread by stateless instance manager (pool). So if you have
> 100
> > > > stateless beans you then have 100 threads doing nothing.
> > > >
> > > > Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> > > > stateless container (but multiple tasks to keep access timeout and
> close
> > > > timeout respected)?
> > > >
> > > > 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>
> > >
> > >
>
Re: stateless pool eviction and threads
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 12 juin 2015 20:55, "Adam Cornett" <ad...@gmail.com> a écrit :
>
> Would it make sense to have the pool size scale up automatically with the
> stateless bean count at an adjustable ratio and a hard floor of 3 or so
> threads?
Hmm maybe i get it wrong but the idea is to prevent it to scale/increase
thread count
> On Jun 12, 2015 2:45 PM, "Mark Struberg" <st...@yahoo.de> wrote:
>
> > +1 Think that makes it also easier to debug and maintain. The current
> > approach simply doesn’t scale well in big deployments.
> >
Well it does but thread dumps are a pain and it is useless
> > LieGrue,
> > strub
> >
> >
> > > Am 12.06.2015 um 09:25 schrieb Romain Manni-Bucau <
rmannibucau@gmail.com
> > >:
> > >
> > > Hi guys,
> > >
> > > already got this issue and Mark pinged me about it yesterday. ATM we
> > have 1
> > > eviction thread by stateless instance manager (pool). So if you have
100
> > > stateless beans you then have 100 threads doing nothing.
> > >
> > > Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> > > stateless container (but multiple tasks to keep access timeout and
close
> > > timeout respected)?
> > >
> > > 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>
> >
> >
Re: stateless pool eviction and threads
Posted by Adam Cornett <ad...@gmail.com>.
Would it make sense to have the pool size scale up automatically with the
stateless bean count at an adjustable ratio and a hard floor of 3 or so
threads?
On Jun 12, 2015 2:45 PM, "Mark Struberg" <st...@yahoo.de> wrote:
> +1 Think that makes it also easier to debug and maintain. The current
> approach simply doesn’t scale well in big deployments.
>
> LieGrue,
> strub
>
>
> > Am 12.06.2015 um 09:25 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi guys,
> >
> > already got this issue and Mark pinged me about it yesterday. ATM we
> have 1
> > eviction thread by stateless instance manager (pool). So if you have 100
> > stateless beans you then have 100 threads doing nothing.
> >
> > Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> > stateless container (but multiple tasks to keep access timeout and close
> > timeout respected)?
> >
> > 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>
>
>
Re: stateless pool eviction and threads
Posted by Mark Struberg <st...@yahoo.de>.
+1 Think that makes it also easier to debug and maintain. The current approach simply doesn’t scale well in big deployments.
LieGrue,
strub
> Am 12.06.2015 um 09:25 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi guys,
>
> already got this issue and Mark pinged me about it yesterday. ATM we have 1
> eviction thread by stateless instance manager (pool). So if you have 100
> stateless beans you then have 100 threads doing nothing.
>
> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> stateless container (but multiple tasks to keep access timeout and close
> timeout respected)?
>
> 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>
Re: stateless pool eviction and threads
Posted by David Blevins <da...@gmail.com>.
On Jun 17, 2015, at 11:37 AM, Matej <gm...@gmail.com> wrote:
> I just wanted to add, as probably our email started this thread. We used
> statelesses instead of singletions(read) because this allowed us to somehow
> "tune" how many requests you let to the DB.
>
> And cause, we had some issue, that the system somehow deadlocks, cause
> Hibernate uses multiple connections per session, we used the Stateless pool
> size parameter for tuning how many requests to process. Otherwise this is
> shifted form the Stateless to the JDBC pool.
Excellent usage. Extremely refreshing to hear of someone using the pooling aspect consciously and effectively!
-David
> 2015-06-15 10:48 GMT+02:00 David Blevins <da...@gmail.com>:
>
>> Side note to readers: best use @Singleton with @Lock(READ) for stateless
>> applications unless there is some specific need to keep a finite pool of
>> instances and lock threads till an instance becomes available.
>>
>> On Mon, Jun 15, 2015 at 9:46 AM, David Blevins <da...@gmail.com>
>> wrote:
>>
>>> The trick is we need to rely on shutdown() being called when the bean is
>>> undeployed to ensure the application can successfully terminate and not
>>> leak timers.
>>>
>>> Sharing a ScheduledExecutorService per application is the best we could
>> do
>>> in that regard. The shutdown logic would still become a bit difficult as
>>> would the Stateless container logic. The StatelessInstanceManager which
>>> builds the pool would also have to build the ScheduledExecutorService and
>>> pass it in, track the ScheduledExecutorService in the ApplicationContext
>> or
>>> ModuleContext and clean it up on undeploy. The StatelessInstanceManager
>>> would have to be careful not to create the ScheduledExecutorService more
>>> than once per app or destroy it more than once per app.
>>>
>>> The pool class would need to remain generic (not specific to stateless
>>> beans) and still be prepared to construct a ScheduledExecutorService if
>> one
>>> wasn't passed in. Similar to what it does now for the regular Executor
>>> service.
>>>
>>>
>>> -David
>>>
>>>
>>> On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> already got this issue and Mark pinged me about it yesterday. ATM we
>> have
>>>> 1
>>>> eviction thread by stateless instance manager (pool). So if you have 100
>>>> stateless beans you then have 100 threads doing nothing.
>>>>
>>>> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
>>>> stateless container (but multiple tasks to keep access timeout and close
>>>> timeout respected)?
>>>>
>>>> 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>
>>>>
>>>
>>>
>>
Re: stateless pool eviction and threads
Posted by Matej <gm...@gmail.com>.
David.
I just wanted to add, as probably our email started this thread. We used
statelesses instead of singletions(read) because this allowed us to somehow
"tune" how many requests you let to the DB.
And cause, we had some issue, that the system somehow deadlocks, cause
Hibernate uses multiple connections per session, we used the Stateless pool
size parameter for tuning how many requests to process. Otherwise this is
shifted form the Stateless to the JDBC pool.
BR
Matej
2015-06-15 10:48 GMT+02:00 David Blevins <da...@gmail.com>:
> Side note to readers: best use @Singleton with @Lock(READ) for stateless
> applications unless there is some specific need to keep a finite pool of
> instances and lock threads till an instance becomes available.
>
> On Mon, Jun 15, 2015 at 9:46 AM, David Blevins <da...@gmail.com>
> wrote:
>
> > The trick is we need to rely on shutdown() being called when the bean is
> > undeployed to ensure the application can successfully terminate and not
> > leak timers.
> >
> > Sharing a ScheduledExecutorService per application is the best we could
> do
> > in that regard. The shutdown logic would still become a bit difficult as
> > would the Stateless container logic. The StatelessInstanceManager which
> > builds the pool would also have to build the ScheduledExecutorService and
> > pass it in, track the ScheduledExecutorService in the ApplicationContext
> or
> > ModuleContext and clean it up on undeploy. The StatelessInstanceManager
> > would have to be careful not to create the ScheduledExecutorService more
> > than once per app or destroy it more than once per app.
> >
> > The pool class would need to remain generic (not specific to stateless
> > beans) and still be prepared to construct a ScheduledExecutorService if
> one
> > wasn't passed in. Similar to what it does now for the regular Executor
> > service.
> >
> >
> > -David
> >
> >
> > On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > > wrote:
> >
> >> Hi guys,
> >>
> >> already got this issue and Mark pinged me about it yesterday. ATM we
> have
> >> 1
> >> eviction thread by stateless instance manager (pool). So if you have 100
> >> stateless beans you then have 100 threads doing nothing.
> >>
> >> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> >> stateless container (but multiple tasks to keep access timeout and close
> >> timeout respected)?
> >>
> >> 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>
> >>
> >
> >
>
Re: stateless pool eviction and threads
Posted by Romain Manni-Bucau <rm...@gmail.com>.
no, removeOnCancel
this mainly removes the task from the pool queue on a legit cancel call (ie
returning true)
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>
2015-06-17 2:04 GMT+02:00 David Blevins <da...@gmail.com>:
> What flag is this?
>
> Do you mean mayInterruptIfRunning?
>
>
> -David
>
> On Jun 17, 2015, at 12:57 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > right forgot to set remove on cancel flag on, will do in a min
> >
> >
> > 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>
> >
> > 2015-06-17 1:34 GMT+02:00 David Blevins <da...@gmail.com>:
> >
> >> On Jun 16, 2015, at 4:41 AM, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>
> >>> Le 16 juin 2015 02:04, "David Blevins" <da...@gmail.com> a
> >> écrit :
> >>>>
> >>>> On Jun 15, 2015, at 7:26 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >>> wrote:
> >>>>
> >>>>>>
> >>>>>>
> >>>>>>> The trick is we need to rely on shutdown() being called when the
> bean
> >>> is
> >>>>>>> undeployed to ensure the application can successfully terminate and
> >>> not
> >>>>>>> leak timers.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> we can use ScheduledTask#cancel then
> >>>>>
> >>>>> will change it and add a flag to go back to previous behavior if
> >> desired
> >>>>
> >>>> No need for a flag if it works.
> >>>>
> >>>> The cancel as opposed to shutdown has no wait time yet can return
> false
> >>> signifying the timer will continue to fire.
> >>>>
> >>>> We'd have to test it to ensure it works, but in the event cancel
> returns
> >>> false we might want to call get(long, TimeUnit) on the future to see if
> >> we
> >>> can wait for completion and try the cancel again.
> >>>>
> >>>
> >>> No, would block shutdown. We already wait for completion not
> interrupting
> >>> the task.
> >>
> >> Can you expand on that? The goal is definitely to block undeploy till
> >> undeploy is actually complete.
> >>
> >> I checked out the code for ScheduledExecutorService yesterday and it
> >> appeared the cancel call will not remove the timer if the timer is being
> >> currently fired nor will it wait for the timer to complete and remove it
> >> afterwards. This means that the sweeper will stay running and the app
> will
> >> leak.
> >>
> >>
> >> -David
> >>
> >>
>
>
Re: stateless pool eviction and threads
Posted by David Blevins <da...@gmail.com>.
What flag is this?
Do you mean mayInterruptIfRunning?
-David
On Jun 17, 2015, at 12:57 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> right forgot to set remove on cancel flag on, will do in a min
>
>
> 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>
>
> 2015-06-17 1:34 GMT+02:00 David Blevins <da...@gmail.com>:
>
>> On Jun 16, 2015, at 4:41 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> Le 16 juin 2015 02:04, "David Blevins" <da...@gmail.com> a
>> écrit :
>>>>
>>>> On Jun 15, 2015, at 7:26 PM, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>>
>>>>>>
>>>>>>
>>>>>>> The trick is we need to rely on shutdown() being called when the bean
>>> is
>>>>>>> undeployed to ensure the application can successfully terminate and
>>> not
>>>>>>> leak timers.
>>>>>>>
>>>>>>
>>>>>
>>>>> we can use ScheduledTask#cancel then
>>>>>
>>>>> will change it and add a flag to go back to previous behavior if
>> desired
>>>>
>>>> No need for a flag if it works.
>>>>
>>>> The cancel as opposed to shutdown has no wait time yet can return false
>>> signifying the timer will continue to fire.
>>>>
>>>> We'd have to test it to ensure it works, but in the event cancel returns
>>> false we might want to call get(long, TimeUnit) on the future to see if
>> we
>>> can wait for completion and try the cancel again.
>>>>
>>>
>>> No, would block shutdown. We already wait for completion not interrupting
>>> the task.
>>
>> Can you expand on that? The goal is definitely to block undeploy till
>> undeploy is actually complete.
>>
>> I checked out the code for ScheduledExecutorService yesterday and it
>> appeared the cancel call will not remove the timer if the timer is being
>> currently fired nor will it wait for the timer to complete and remove it
>> afterwards. This means that the sweeper will stay running and the app will
>> leak.
>>
>>
>> -David
>>
>>
Re: stateless pool eviction and threads
Posted by Romain Manni-Bucau <rm...@gmail.com>.
right forgot to set remove on cancel flag on, will do in a min
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>
2015-06-17 1:34 GMT+02:00 David Blevins <da...@gmail.com>:
> On Jun 16, 2015, at 4:41 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le 16 juin 2015 02:04, "David Blevins" <da...@gmail.com> a
> écrit :
> >>
> >> On Jun 15, 2015, at 7:26 PM, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >>
> >>>>
> >>>>
> >>>>> The trick is we need to rely on shutdown() being called when the bean
> > is
> >>>>> undeployed to ensure the application can successfully terminate and
> > not
> >>>>> leak timers.
> >>>>>
> >>>>
> >>>
> >>> we can use ScheduledTask#cancel then
> >>>
> >>> will change it and add a flag to go back to previous behavior if
> desired
> >>
> >> No need for a flag if it works.
> >>
> >> The cancel as opposed to shutdown has no wait time yet can return false
> > signifying the timer will continue to fire.
> >>
> >> We'd have to test it to ensure it works, but in the event cancel returns
> > false we might want to call get(long, TimeUnit) on the future to see if
> we
> > can wait for completion and try the cancel again.
> >>
> >
> > No, would block shutdown. We already wait for completion not interrupting
> > the task.
>
> Can you expand on that? The goal is definitely to block undeploy till
> undeploy is actually complete.
>
> I checked out the code for ScheduledExecutorService yesterday and it
> appeared the cancel call will not remove the timer if the timer is being
> currently fired nor will it wait for the timer to complete and remove it
> afterwards. This means that the sweeper will stay running and the app will
> leak.
>
>
> -David
>
>
Re: stateless pool eviction and threads
Posted by David Blevins <da...@gmail.com>.
On Jun 16, 2015, at 4:41 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Le 16 juin 2015 02:04, "David Blevins" <da...@gmail.com> a écrit :
>>
>> On Jun 15, 2015, at 7:26 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>
>>>>
>>>>
>>>>> The trick is we need to rely on shutdown() being called when the bean
> is
>>>>> undeployed to ensure the application can successfully terminate and
> not
>>>>> leak timers.
>>>>>
>>>>
>>>
>>> we can use ScheduledTask#cancel then
>>>
>>> will change it and add a flag to go back to previous behavior if desired
>>
>> No need for a flag if it works.
>>
>> The cancel as opposed to shutdown has no wait time yet can return false
> signifying the timer will continue to fire.
>>
>> We'd have to test it to ensure it works, but in the event cancel returns
> false we might want to call get(long, TimeUnit) on the future to see if we
> can wait for completion and try the cancel again.
>>
>
> No, would block shutdown. We already wait for completion not interrupting
> the task.
Can you expand on that? The goal is definitely to block undeploy till undeploy is actually complete.
I checked out the code for ScheduledExecutorService yesterday and it appeared the cancel call will not remove the timer if the timer is being currently fired nor will it wait for the timer to complete and remove it afterwards. This means that the sweeper will stay running and the app will leak.
-David
Re: stateless pool eviction and threads
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 16 juin 2015 02:04, "David Blevins" <da...@gmail.com> a écrit :
>
> On Jun 15, 2015, at 7:26 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> >>
> >>
> >>> The trick is we need to rely on shutdown() being called when the bean
is
> >>> undeployed to ensure the application can successfully terminate and
not
> >>> leak timers.
> >>>
> >>
> >
> > we can use ScheduledTask#cancel then
> >
> > will change it and add a flag to go back to previous behavior if desired
>
> No need for a flag if it works.
>
> The cancel as opposed to shutdown has no wait time yet can return false
signifying the timer will continue to fire.
>
> We'd have to test it to ensure it works, but in the event cancel returns
false we might want to call get(long, TimeUnit) on the future to see if we
can wait for completion and try the cancel again.
>
No, would block shutdown. We already wait for completion not interrupting
the task.
> Would take some playing around to ensure this actually would work.
>
>
> -David
>
Re: stateless pool eviction and threads
Posted by David Blevins <da...@gmail.com>.
On Jun 15, 2015, at 7:26 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>
>>
>>> The trick is we need to rely on shutdown() being called when the bean is
>>> undeployed to ensure the application can successfully terminate and not
>>> leak timers.
>>>
>>
>
> we can use ScheduledTask#cancel then
>
> will change it and add a flag to go back to previous behavior if desired
No need for a flag if it works.
The cancel as opposed to shutdown has no wait time yet can return false signifying the timer will continue to fire.
We'd have to test it to ensure it works, but in the event cancel returns false we might want to call get(long, TimeUnit) on the future to see if we can wait for completion and try the cancel again.
Would take some playing around to ensure this actually would work.
-David
Re: stateless pool eviction and threads
Posted by Romain Manni-Bucau <rm...@gmail.com>.
https://issues.apache.org/jira/browse/TOMEE-1604
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>
2015-06-15 20:26 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> > The trick is we need to rely on shutdown() being called when the bean is
>> > undeployed to ensure the application can successfully terminate and not
>> > leak timers.
>> >
>>
>
> we can use ScheduledTask#cancel then
>
> will change it and add a flag to go back to previous behavior if desired
>
>
>> > Sharing a ScheduledExecutorService per application is the best we could
>> do
>> > in that regard. The shutdown logic would still become a bit difficult
>> as
>> > would the Stateless container logic. The StatelessInstanceManager which
>> > builds the pool would also have to build the ScheduledExecutorService
>> and
>> > pass it in, track the ScheduledExecutorService in the
>> ApplicationContext or
>> > ModuleContext and clean it up on undeploy. The StatelessInstanceManager
>> > would have to be careful not to create the ScheduledExecutorService more
>> > than once per app or destroy it more than once per app.
>> >
>> > The pool class would need to remain generic (not specific to stateless
>> > beans) and still be prepared to construct a ScheduledExecutorService if
>> one
>> > wasn't passed in. Similar to what it does now for the regular Executor
>> > service.
>> >
>> >
>> > -David
>> >
>> >
>> > On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com
>> > > wrote:
>> >
>> >> Hi guys,
>> >>
>> >> already got this issue and Mark pinged me about it yesterday. ATM we
>> have
>> >> 1
>> >> eviction thread by stateless instance manager (pool). So if you have
>> 100
>> >> stateless beans you then have 100 threads doing nothing.
>> >>
>> >> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
>> >> stateless container (but multiple tasks to keep access timeout and
>> close
>> >> timeout respected)?
>> >>
>> >> 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>
>> >>
>> >
>> >
>>
>
>
Re: stateless pool eviction and threads
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 15 juin 2015 20:21, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> >
> > will change it and add a flag to go back to previous behavior if desired
>
> Side note on that: sometimes it makes sense to create switches to switch
back to custom behaviour. But our code becomes increasingly hard to
maintain that way.
Well here it is really literally 3 lines
>
> LieGrue,
> strub
>
> > Am 15.06.2015 um 20:26 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>:
> >
> >>
> >>
> >>> The trick is we need to rely on shutdown() being called when the bean
is
> >>> undeployed to ensure the application can successfully terminate and
not
> >>> leak timers.
> >>>
> >>
> >
> > we can use ScheduledTask#cancel then
> >
> > will change it and add a flag to go back to previous behavior if desired
> >
> >
> >>> Sharing a ScheduledExecutorService per application is the best we
could
> >> do
> >>> in that regard. The shutdown logic would still become a bit
difficult as
> >>> would the Stateless container logic. The StatelessInstanceManager
which
> >>> builds the pool would also have to build the ScheduledExecutorService
and
> >>> pass it in, track the ScheduledExecutorService in the
ApplicationContext
> >> or
> >>> ModuleContext and clean it up on undeploy. The
StatelessInstanceManager
> >>> would have to be careful not to create the ScheduledExecutorService
more
> >>> than once per app or destroy it more than once per app.
> >>>
> >>> The pool class would need to remain generic (not specific to stateless
> >>> beans) and still be prepared to construct a ScheduledExecutorService
if
> >> one
> >>> wasn't passed in. Similar to what it does now for the regular
Executor
> >>> service.
> >>>
> >>>
> >>> -David
> >>>
> >>>
> >>> On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <
> >> rmannibucau@gmail.com
> >>>> wrote:
> >>>
> >>>> Hi guys,
> >>>>
> >>>> already got this issue and Mark pinged me about it yesterday. ATM we
> >> have
> >>>> 1
> >>>> eviction thread by stateless instance manager (pool). So if you have
100
> >>>> stateless beans you then have 100 threads doing nothing.
> >>>>
> >>>> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> >>>> stateless container (but multiple tasks to keep access timeout and
close
> >>>> timeout respected)?
> >>>>
> >>>> 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>
> >>>>
> >>>
> >>>
> >>
>
Re: stateless pool eviction and threads
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
+1
The number of system properties keeps increasing and I'm sometimes lost
myself.
Don't have a lot of solutions to propose, but probably it's time to find
something more sane.
just my 2 cts
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, Jun 15, 2015 at 8:21 PM, Mark Struberg <st...@yahoo.de> wrote:
> >
> > will change it and add a flag to go back to previous behavior if desired
>
> Side note on that: sometimes it makes sense to create switches to switch
> back to custom behaviour. But our code becomes increasingly hard to
> maintain that way.
>
> LieGrue,
> strub
>
> > Am 15.06.2015 um 20:26 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> >>
> >>
> >>> The trick is we need to rely on shutdown() being called when the bean
> is
> >>> undeployed to ensure the application can successfully terminate and not
> >>> leak timers.
> >>>
> >>
> >
> > we can use ScheduledTask#cancel then
> >
> > will change it and add a flag to go back to previous behavior if desired
> >
> >
> >>> Sharing a ScheduledExecutorService per application is the best we could
> >> do
> >>> in that regard. The shutdown logic would still become a bit difficult
> as
> >>> would the Stateless container logic. The StatelessInstanceManager which
> >>> builds the pool would also have to build the ScheduledExecutorService
> and
> >>> pass it in, track the ScheduledExecutorService in the
> ApplicationContext
> >> or
> >>> ModuleContext and clean it up on undeploy. The
> StatelessInstanceManager
> >>> would have to be careful not to create the ScheduledExecutorService
> more
> >>> than once per app or destroy it more than once per app.
> >>>
> >>> The pool class would need to remain generic (not specific to stateless
> >>> beans) and still be prepared to construct a ScheduledExecutorService if
> >> one
> >>> wasn't passed in. Similar to what it does now for the regular Executor
> >>> service.
> >>>
> >>>
> >>> -David
> >>>
> >>>
> >>> On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <
> >> rmannibucau@gmail.com
> >>>> wrote:
> >>>
> >>>> Hi guys,
> >>>>
> >>>> already got this issue and Mark pinged me about it yesterday. ATM we
> >> have
> >>>> 1
> >>>> eviction thread by stateless instance manager (pool). So if you have
> 100
> >>>> stateless beans you then have 100 threads doing nothing.
> >>>>
> >>>> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> >>>> stateless container (but multiple tasks to keep access timeout and
> close
> >>>> timeout respected)?
> >>>>
> >>>> 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>
> >>>>
> >>>
> >>>
> >>
>
>
Re: stateless pool eviction and threads
Posted by Mark Struberg <st...@yahoo.de>.
>
> will change it and add a flag to go back to previous behavior if desired
Side note on that: sometimes it makes sense to create switches to switch back to custom behaviour. But our code becomes increasingly hard to maintain that way.
LieGrue,
strub
> Am 15.06.2015 um 20:26 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
>>
>>
>>> The trick is we need to rely on shutdown() being called when the bean is
>>> undeployed to ensure the application can successfully terminate and not
>>> leak timers.
>>>
>>
>
> we can use ScheduledTask#cancel then
>
> will change it and add a flag to go back to previous behavior if desired
>
>
>>> Sharing a ScheduledExecutorService per application is the best we could
>> do
>>> in that regard. The shutdown logic would still become a bit difficult as
>>> would the Stateless container logic. The StatelessInstanceManager which
>>> builds the pool would also have to build the ScheduledExecutorService and
>>> pass it in, track the ScheduledExecutorService in the ApplicationContext
>> or
>>> ModuleContext and clean it up on undeploy. The StatelessInstanceManager
>>> would have to be careful not to create the ScheduledExecutorService more
>>> than once per app or destroy it more than once per app.
>>>
>>> The pool class would need to remain generic (not specific to stateless
>>> beans) and still be prepared to construct a ScheduledExecutorService if
>> one
>>> wasn't passed in. Similar to what it does now for the regular Executor
>>> service.
>>>
>>>
>>> -David
>>>
>>>
>>> On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> already got this issue and Mark pinged me about it yesterday. ATM we
>> have
>>>> 1
>>>> eviction thread by stateless instance manager (pool). So if you have 100
>>>> stateless beans you then have 100 threads doing nothing.
>>>>
>>>> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
>>>> stateless container (but multiple tasks to keep access timeout and close
>>>> timeout respected)?
>>>>
>>>> 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>
>>>>
>>>
>>>
>>
Re: stateless pool eviction and threads
Posted by Romain Manni-Bucau <rm...@gmail.com>.
>
>
> > The trick is we need to rely on shutdown() being called when the bean is
> > undeployed to ensure the application can successfully terminate and not
> > leak timers.
> >
>
we can use ScheduledTask#cancel then
will change it and add a flag to go back to previous behavior if desired
> > Sharing a ScheduledExecutorService per application is the best we could
> do
> > in that regard. The shutdown logic would still become a bit difficult as
> > would the Stateless container logic. The StatelessInstanceManager which
> > builds the pool would also have to build the ScheduledExecutorService and
> > pass it in, track the ScheduledExecutorService in the ApplicationContext
> or
> > ModuleContext and clean it up on undeploy. The StatelessInstanceManager
> > would have to be careful not to create the ScheduledExecutorService more
> > than once per app or destroy it more than once per app.
> >
> > The pool class would need to remain generic (not specific to stateless
> > beans) and still be prepared to construct a ScheduledExecutorService if
> one
> > wasn't passed in. Similar to what it does now for the regular Executor
> > service.
> >
> >
> > -David
> >
> >
> > On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > > wrote:
> >
> >> Hi guys,
> >>
> >> already got this issue and Mark pinged me about it yesterday. ATM we
> have
> >> 1
> >> eviction thread by stateless instance manager (pool). So if you have 100
> >> stateless beans you then have 100 threads doing nothing.
> >>
> >> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> >> stateless container (but multiple tasks to keep access timeout and close
> >> timeout respected)?
> >>
> >> 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>
> >>
> >
> >
>
Re: stateless pool eviction and threads
Posted by David Blevins <da...@gmail.com>.
Side note to readers: best use @Singleton with @Lock(READ) for stateless
applications unless there is some specific need to keep a finite pool of
instances and lock threads till an instance becomes available.
On Mon, Jun 15, 2015 at 9:46 AM, David Blevins <da...@gmail.com>
wrote:
> The trick is we need to rely on shutdown() being called when the bean is
> undeployed to ensure the application can successfully terminate and not
> leak timers.
>
> Sharing a ScheduledExecutorService per application is the best we could do
> in that regard. The shutdown logic would still become a bit difficult as
> would the Stateless container logic. The StatelessInstanceManager which
> builds the pool would also have to build the ScheduledExecutorService and
> pass it in, track the ScheduledExecutorService in the ApplicationContext or
> ModuleContext and clean it up on undeploy. The StatelessInstanceManager
> would have to be careful not to create the ScheduledExecutorService more
> than once per app or destroy it more than once per app.
>
> The pool class would need to remain generic (not specific to stateless
> beans) and still be prepared to construct a ScheduledExecutorService if one
> wasn't passed in. Similar to what it does now for the regular Executor
> service.
>
>
> -David
>
>
> On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> > wrote:
>
>> Hi guys,
>>
>> already got this issue and Mark pinged me about it yesterday. ATM we have
>> 1
>> eviction thread by stateless instance manager (pool). So if you have 100
>> stateless beans you then have 100 threads doing nothing.
>>
>> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
>> stateless container (but multiple tasks to keep access timeout and close
>> timeout respected)?
>>
>> 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>
>>
>
>
Re: stateless pool eviction and threads
Posted by David Blevins <da...@gmail.com>.
The trick is we need to rely on shutdown() being called when the bean is
undeployed to ensure the application can successfully terminate and not
leak timers.
Sharing a ScheduledExecutorService per application is the best we could do
in that regard. The shutdown logic would still become a bit difficult as
would the Stateless container logic. The StatelessInstanceManager which
builds the pool would also have to build the ScheduledExecutorService and
pass it in, track the ScheduledExecutorService in the ApplicationContext or
ModuleContext and clean it up on undeploy. The StatelessInstanceManager
would have to be careful not to create the ScheduledExecutorService more
than once per app or destroy it more than once per app.
The pool class would need to remain generic (not specific to stateless
beans) and still be prepared to construct a ScheduledExecutorService if one
wasn't passed in. Similar to what it does now for the regular Executor
service.
-David
On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi guys,
>
> already got this issue and Mark pinged me about it yesterday. ATM we have 1
> eviction thread by stateless instance manager (pool). So if you have 100
> stateless beans you then have 100 threads doing nothing.
>
> Do we want to reduce it to N fixed threads (default to 3 maybe?) per
> stateless container (but multiple tasks to keep access timeout and close
> timeout respected)?
>
> 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>
>