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 < [email protected]>: > 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:[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. >
