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:[email protected]]
Sent: vendredi 2 juin 2017 18:02
To: [email protected]
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 <
[email protected]>:
> 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.
