Assigning different thread pool for different URL/URI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Assigning different thread pool for different URL/URI

Franos13
Hello everyone,

I have read some TomEE/Tomcat documentations about thread pool settings.
Let me first explain my understanding in order to see if this one is right or wrong:
      - With the default TomEE configuration: there is a default limit (200) for getting more thread if we don't set the maxThread , right ?
      - Thread pool management is only managed at Connector level, right ?
      - We may assign a dedicated thread pool for a Connector using an Executor, right ?

The goal I want to reach: have a dedicated thread pool per URI or a set of URIs.
Is it possible using some TomEE configuration to set a dedicated thread pool per URI (I don't think so but want to check) ?

One more question: when the thread max  + acceptCount is reached, does TomEE return 503 ?

Best Regards.



________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
Reply | Threaded
Open this post in threaded view
|

Re: Assigning different thread pool for different URL/URI

Romain Manni-Bucau
Hi François,

it is more tomcat questions but let's try to help on them inline


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-02 17:49 GMT+02:00 COURTAULT Francois <
[hidden email]>:

> Hello everyone,
>
> I have read some TomEE/Tomcat documentations about thread pool settings.
> Let me first explain my understanding in order to see if this one is right
> or wrong:
>       - With the default TomEE configuration: there is a default limit
> (200) for getting more thread if we don't set the maxThread , right ?
>

yes, defaults are in org.apache.catalina.core.StandardThreadExecutor:

protected int maxThreads = 200;



>       - Thread pool management is only managed at Connector level, right ?
>

For http requests yes but as TomEE you also have concurrency utilities, ejb
pools, etc...


>       - We may assign a dedicated thread pool for a Connector using an
> Executor, right ?
>

yes by "reference" (name)


>
> The goal I want to reach: have a dedicated thread pool per URI or a set of
> URIs.
>

This is not easy by default but if you delegate the job in another pool
(app pool) and use async context you dont need to do it at tomcat level but
you can control it at app level.


> Is it possible using some TomEE configuration to set a dedicated thread
> pool per URI (I don't think so but want to check) ?
>

The thread is needed too early to do it I fear but I'm sure you can
"rephrase" it to enable your use case.


>
> One more question: when the thread max  + acceptCount is reached, does
> TomEE return 503 ?
>

Hmm, acceptCount is the queue for the socket (like in plain C) - it is
actually "backlog" in the code. It is platform dependent often - dont know
if it got sanitized recently  :(. So it is not guaranteed AFAIK.

I'm tempted to say you can give it a try putting low value you should
reproduce it easily - would recommand to test on the samle platform than
your prod for the mentionned reason ^^ :).


>
> Best Regards.
>
>
>
> ________________________________
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>
Reply | Threaded
Open this post in threaded view
|

RE: Assigning different thread pool for different URL/URI

Franos13
Hello Romain,

Thanks a lot for your answers :-)

Any rule for matching the threading of Tomcat and the number of beans, which is global, right ? in the pool of TomEE.
According to me it is quite complicated to handle. We should have something like:
         - UseCase 1 involves EJB A, B and C using at most 10 concurrent requests
         - UseCase 2 involves EJB D, E using at most 20 concurrent requests
This means that we should set the MaxThread to 30 (20+10) and the number of beans in the pool to: 30 (3 beans*10 req) + 40 (2 beans*20req)=70 beans in the pool
Am I right ?

Regarding " The thread is needed too early to do it I fear but I'm sure you can "rephrase" it to enable your use case."
The use case is that we had a situation where all threads were blocked due to an application issue and we still wanted to monitor our application using REST calls but we
can't because all the Thread Pool has been consumed.
We found a workaround by having added a new Connector using a different port in server.xml but, according to me, it is not a safe situation because you may use this new port
again to run applicative requests even if we know that our system is in a bad shape regarding resource allocation !  This is why I was thinking that having a dedicated thread pool per URI
could be a smarter solution.

Best Regards.

-----Original Message-----
From: Romain Manni-Bucau [mailto:[hidden email]]
Sent: vendredi 2 juin 2017 18:02
To: [hidden email]
Subject: Re: Assigning different thread pool for different URL/URI

Hi François,

it is more tomcat questions but let's try to help on them inline


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-02 17:49 GMT+02:00 COURTAULT Francois <
[hidden email]>:

> Hello everyone,
>
> I have read some TomEE/Tomcat documentations about thread pool settings.
> Let me first explain my understanding in order to see if this one is
> right or wrong:
>       - With the default TomEE configuration: there is a default limit
> (200) for getting more thread if we don't set the maxThread , right ?
>

yes, defaults are in org.apache.catalina.core.StandardThreadExecutor:

protected int maxThreads = 200;



>       - Thread pool management is only managed at Connector level, right ?
>

For http requests yes but as TomEE you also have concurrency utilities, ejb pools, etc...


>       - We may assign a dedicated thread pool for a Connector using an
> Executor, right ?
>

yes by "reference" (name)


>
> The goal I want to reach: have a dedicated thread pool per URI or a
> set of URIs.
>

This is not easy by default but if you delegate the job in another pool (app pool) and use async context you dont need to do it at tomcat level but you can control it at app level.


> Is it possible using some TomEE configuration to set a dedicated
> thread pool per URI (I don't think so but want to check) ?
>

The thread is needed too early to do it I fear but I'm sure you can "rephrase" it to enable your use case.


>
> One more question: when the thread max  + acceptCount is reached, does
> TomEE return 503 ?
>

Hmm, acceptCount is the queue for the socket (like in plain C) - it is actually "backlog" in the code. It is platform dependent often - dont know if it got sanitized recently  :(. So it is not guaranteed AFAIK.

I'm tempted to say you can give it a try putting low value you should reproduce it easily - would recommand to test on the samle platform than your prod for the mentionned reason ^^ :).


>
> Best Regards.
>
>
>
> ________________________________
>  This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>
________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
Reply | Threaded
Open this post in threaded view
|

Re: Assigning different thread pool for different URL/URI

Romain Manni-Bucau
Hmm,

Side note: don't forget to add resources pool (database for instance) into
the game which can lock too if too low compared to the tuned
#threads/#instances


2017-06-02 19:21 GMT+02:00 COURTAULT Francois <
[hidden email]>:

> Hello Romain,
>
> Thanks a lot for your answers :-)
>
> Any rule for matching the threading of Tomcat and the number of beans,
> which is global, right ? in the pool of TomEE.
> According to me it is quite complicated to handle. We should have
> something like:
>          - UseCase 1 involves EJB A, B and C using at most 10 concurrent
> requests
>          - UseCase 2 involves EJB D, E using at most 20 concurrent requests
> This means that we should set the MaxThread to 30 (20+10) and the number
> of beans in the pool to: 30 (3 beans*10 req) + 40 (2 beans*20req)=70 beans
> in the pool
> Am I right ?
>


Theorically yes, in practise a bit more to ensure the transitions are
smooths ("no risk"). That said you can likely use @Singleton or plain cdi
beans to avoid to have that pool which just adds a lock to the system these
days.

>
> Regarding " The thread is needed too early to do it I fear but I'm sure
> you can "rephrase" it to enable your use case."
> The use case is that we had a situation where all threads were blocked due
> to an application issue and we still wanted to monitor our application
> using REST calls but we
> can't because all the Thread Pool has been consumed.
> We found a workaround by having added a new Connector using a different
> port in server.xml but, according to me, it is not a safe situation because
> you may use this new port
> again to run applicative requests even if we know that our system is in a
> bad shape regarding resource allocation !  This is why I was thinking that
> having a dedicated thread pool per URI
> could be a smarter solution.
>


You would still lock the system somehow if there is an app bug. Hystix
command pattern quite break EE (thread locals) but allows to control it at
a cost in the impl. That said I'm tempted to say: ensure you bench your app
before going live and you shouldnt have issues without having to invest in
any lib or big refactoring of such nature.


>
> Best Regards.
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:[hidden email]]
> Sent: vendredi 2 juin 2017 18:02
> To: [hidden email]
> Subject: Re: Assigning different thread pool for different URL/URI
>
> Hi François,
>
> it is more tomcat questions but let's try to help on them inline
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog <
> https://blog-rmannibucau.rhcloud.com> | Old Blog <
> http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <
> https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-02 17:49 GMT+02:00 COURTAULT Francois <
> [hidden email]>:
>
> > Hello everyone,
> >
> > I have read some TomEE/Tomcat documentations about thread pool settings.
> > Let me first explain my understanding in order to see if this one is
> > right or wrong:
> >       - With the default TomEE configuration: there is a default limit
> > (200) for getting more thread if we don't set the maxThread , right ?
> >
>
> yes, defaults are in org.apache.catalina.core.StandardThreadExecutor:
>
> protected int maxThreads = 200;
>
>
>
> >       - Thread pool management is only managed at Connector level, right
> ?
> >
>
> For http requests yes but as TomEE you also have concurrency utilities,
> ejb pools, etc...
>
>
> >       - We may assign a dedicated thread pool for a Connector using an
> > Executor, right ?
> >
>
> yes by "reference" (name)
>
>
> >
> > The goal I want to reach: have a dedicated thread pool per URI or a
> > set of URIs.
> >
>
> This is not easy by default but if you delegate the job in another pool
> (app pool) and use async context you dont need to do it at tomcat level but
> you can control it at app level.
>
>
> > Is it possible using some TomEE configuration to set a dedicated
> > thread pool per URI (I don't think so but want to check) ?
> >
>
> The thread is needed too early to do it I fear but I'm sure you can
> "rephrase" it to enable your use case.
>
>
> >
> > One more question: when the thread max  + acceptCount is reached, does
> > TomEE return 503 ?
> >
>
> Hmm, acceptCount is the queue for the socket (like in plain C) - it is
> actually "backlog" in the code. It is platform dependent often - dont know
> if it got sanitized recently  :(. So it is not guaranteed AFAIK.
>
> I'm tempted to say you can give it a try putting low value you should
> reproduce it easily - would recommand to test on the samle platform than
> your prod for the mentionned reason ^^ :).
>
>
> >
> > Best Regards.
> >
> >
> >
> > ________________________________
> >  This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any unauthorized
> > use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> > for the message if altered, changed or falsified. If you are not the
> > intended recipient of this message, please delete it and notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus.
> >
> ________________________________
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>