Yes the standard JDK ThreadPoolExecutor behavior is bad.
Here is a good thread describing how to fix ThreadPoolExecutor to behave how it
should be.
https://stackoverflow.com/questions/19528304/how-to-get-the-threadpoolexecutor-to-increase-threads-to-max-before-queueing
Obviously Tomcat had
On Tue, Mar 12, 2024 at 5:55 PM wrote:
>
> All,
>
>
> > -Original Message-
> > From: Christopher Schultz
> > Sent: Tuesday, March 12, 2024 8:31 AM
> > To: users@tomcat.apache.org
> > Subject: Re: When does Tomcat add and remove threads?
> &g
All,
> -Original Message-
> From: Christopher Schultz
> Sent: Tuesday, March 12, 2024 8:31 AM
> To: users@tomcat.apache.org
> Subject: Re: When does Tomcat add and remove threads?
>
> John,
>
> On 3/11/24 18:14, john.e.gr...@wellsfargo.com.INVALID wrote:
&g
John,
On 3/11/24 18:14, john.e.gr...@wellsfargo.com.INVALID wrote:
From: Christopher Schultz
Sent: Monday, March 11, 2024 5:09 PM
>
On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:
I am using Tomcat 9.x.
When does Tomcat add and remove threads from its internal thread
p
Chris,
From: Christopher Schultz
Sent: Monday, March 11, 2024 5:09 PM
To: users@tomcat.apache.org
Subject: Re: When does Tomcat add and remove threads?
John,
On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:
> I am using Tomcat 9.x.
>
>
John,
On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:
I am using Tomcat 9.x.
When does Tomcat add and remove threads from its internal thread
pool? I'm talking about the threads with names like
http-nio-8080-exec-1. It appears the thread pool is Tomcat's own
ThreadPoolExecutor
I am using Tomcat 9.x.
When does Tomcat add and remove threads from its internal thread pool? I'm
talking about the threads with names like http-nio-8080-exec-1. It appears the
thread pool is Tomcat's own ThreadPoolExecutor but I don't see the exact
behavior documented. I'm familiar
On 07/09/2023 15:41, Christopher Schultz wrote:
On 9/6/23 16:29, Mark Thomas wrote:
There isn't
much point using an executor with virtual threads.
Okay then perche
https://tomcat.apache.org/tomcat-11.0-doc/config/executor.html#Virtual_Thread_Implementation ?
That is the internal
rtual" anywhere on that page.
It is a Connector attribute, not an Executor attribute. There isn't much
point using an executor with virtual threads.
Okay then perche
https://tomcat.apache.org/tomcat-11.0-doc/config/executor.html#Virtual_Thread_Implem
Connector attribute, not an Executor attribute. There isn't much
point using an executor with virtual threads.
For those of you that are finding this topic interesting, I'll have a
talk on this at the ASF conference, Community Over Code in Halifax.
https://communityovercode.org/schedule-list/
Mark,
On 9/6/23 03:29, Mark Thomas wrote:
On 05/09/2023 22:02, Christopher Schultz wrote:
Mark,
On 9/5/23 15:55, Mark Thomas wrote:
On 05/09/2023 20:38, Christopher Schultz wrote:
All,
I have some questions about Virtual Threads and their use within
Tomcat. Note that only Tomcat 11
On 05/09/2023 22:02, Christopher Schultz wrote:
Mark,
On 9/5/23 15:55, Mark Thomas wrote:
On 05/09/2023 20:38, Christopher Schultz wrote:
All,
I have some questions about Virtual Threads and their use within
Tomcat. Note that only Tomcat 11 currently has support for Virtual
Threads when
Mark,
On 9/5/23 15:55, Mark Thomas wrote:
On 05/09/2023 20:38, Christopher Schultz wrote:
All,
I have some questions about Virtual Threads and their use within
Tomcat. Note that only Tomcat 11 currently has support for Virtual
Threads when running on a version 19 or later JVM.
Not quite
On 05/09/2023 20:38, Christopher Schultz wrote:
All,
I have some questions about Virtual Threads and their use within Tomcat.
Note that only Tomcat 11 currently has support for Virtual Threads when
running on a version 19 or later JVM.
Not quite. All current versions support virtual threads
All,
I have some questions about Virtual Threads and their use within Tomcat.
Note that only Tomcat 11 currently has support for Virtual Threads when
running on a version 19 or later JVM.
My (admittedly limited) understanding is that the use of Virtual
Threads, specifically within Tomcat
iel,
How did you trigger the pinning? I'm running some basic tests with
-Djdk.tracePinnedThreads=short and I'm not seeing any pinned threads
reported.
Mark
On 07/07/2023 13:45, Daniel Andres Pelaez Lopez wrote:
Mark,
Thanks for letting me know. I will wait for the August release to test.
Rega
> >
> >
> > On 25/07/2023 10:19, Mark Thomas wrote:
> >> Daniel,
> >>
> >> How did you trigger the pinning? I'm running some basic tests with
> >> -Djdk.tracePinnedThreads=short and I'm not seeing any pinned threads
> >> reported.
&
send I managed to trigger the
issue.
Mark
On 25/07/2023 10:19, Mark Thomas wrote:
Daniel,
How did you trigger the pinning? I'm running some basic tests with
-Djdk.tracePinnedThreads=short and I'm not seeing any pinned threads
reported.
Mark
On 07/07/2023 13:45, Daniel Andres Pelaez Lopez
Never mind. Pretty much as soon as I hit send I managed to trigger the
issue.
Mark
On 25/07/2023 10:19, Mark Thomas wrote:
Daniel,
How did you trigger the pinning? I'm running some basic tests with
-Djdk.tracePinnedThreads=short and I'm not seeing any pinned threads
reported.
Mark
Daniel,
How did you trigger the pinning? I'm running some basic tests with
-Djdk.tracePinnedThreads=short and I'm not seeing any pinned threads
reported.
Mark
On 07/07/2023 13:45, Daniel Andres Pelaez Lopez wrote:
Mark,
Thanks for letting me know. I will wait for the August release
Mark,
Thanks for letting me know. I will wait for the August release to test.
Regards.
El jue, 6 jul 2023 a las 15:13, Mark Thomas () escribió:
>
>
> 6 Jul 2023 20:09:01 Daniel Andres Pelaez Lopez :
>
> > I am aware Tomcat community did a great effort to move Tomat to
&
6 Jul 2023 20:09:01 Daniel Andres Pelaez Lopez :
I am aware Tomcat community did a great effort to move Tomat to
Virtual Threads friendly, but I am not sure why HTTP2 was not part of
that effort?
The plan was always to see where the bottlenecks were as folks start to
experiment with Loom
Hi community,
I am working on a Spring Boot + Tomcat embedded application using
Virtual Threads (https://openjdk.org/jeps/425), and everything looks
great until we activate HTTP2. We started to see the following logs:
Thread[#72,ForkJoinPool-1-worker-9,5,CarrierThreads
:
On Mon, Sep 19, 2022 at 7:45 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
Jon,
On 9/19/22 10:46, Jonathan Yom-Tov wrote:
Sometimes one of our production Tomcats will start with the maximum (200)
number of t
onathan Yom-Tov wrote:
> > Sometimes one of our production Tomcats will start with the maximum (200)
> > number of threads in the https pool. That is, it doesn't start with some
> > minimum and works its way up to the maximum, it immediately starts with
> the
> > ma
Jon,
On 9/19/22 10:46, Jonathan Yom-Tov wrote:
Sometimes one of our production Tomcats will start with the maximum (200)
number of threads in the https pool. That is, it doesn't start with some
minimum and works its way up to the maximum, it immediately starts with the
maximum. There's
If the machine / VM / container you are running Tomcat on can't handle
200 threads you should be using a smaller value for maxThreads.
Mark
On 19/09/2022 15:46, Jonathan Yom-Tov wrote:
hi,
Sometimes one of our production Tomcats will start with the maximum (200)
number of threads
hi,
Sometimes one of our production Tomcats will start with the maximum (200)
number of threads in the https pool. That is, it doesn't start with some
minimum and works its way up to the maximum, it immediately starts with the
maximum. There's no reason for it since most of the threads stay idle
Sahil,
On 5/11/22 13:56, Verma, Sahil wrote:
In our production environment, ApacheTomcat services went down. We
have checked the logs and found below error -
[Thu May 05 10:34:51.441668 2022] [mpm_event:error] [pid 27440:tid
140464737793792] AH00484: server reached MaxRequestWorkers setting,
Thomas
> Sent: Monday, August 23, 2021 3:06 AM
> To: users@tomcat.apache.org
> Subject: Re: clearReferencesThreads issues warning about 2 threads,
> spawned by JDK in printing components
>
> On 23/08/2021 08:10, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>
>
>
> >
Mark,
On 8/23/21 04:05, Mark Thomas wrote:
On 23/08/2021 08:10, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Is there anything, the application can prevent this?
Yes. Call Thread.setContextClassLoader(ClassLoader) before calling the
code that creates those threads, passing the common class
> Is there anything, the application can prevent this?
Yes. Call Thread.setContextClassLoader(ClassLoader) before calling the code
that creates those threads, passing the common class loader.
Afterwards, reset the TCCL back to the web application class loader.
> Should Tomcat mayb
On 23/08/2021 08:10, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Is there anything, the application can prevent this?
Yes. Call Thread.setContextClassLoader(ClassLoader) before calling the
code that creates those threads, passing the common class loader.
Afterwards, reset the TCCL back
, patts);
This triggers the JDK to spawn two threads, which can be seen in the
OpenJDK-Sources:
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java
(see around line no 134 ff)
--> Thread thr = new Thread(null,
hes maximum thread limit. Our application is deployed in
> tomcat. Maximum thread limit of tomcat is 200, so If 200 threads are
> reached, does tomcat provide any logger information?
>
>
>
> We tried making multiple rest calls and reducing max threads to 2-3. We
> fa
Hi,
We have a usecase where we want that our application should indicate when it
reaches maximum thread limit. Our application is deployed in tomcat. Maximum
thread limit of tomcat is 200, so If 200 threads are reached, does tomcat
provide any logger information?
We tried making multiple
make it to this list. You gotta use text to communicate.
If it's not important to know the exact moment you hit your high-water
mark, you could poll Tomcat via JMX to find out what the current
max-threads is and the current active-threads. If you have
active-threads=max-threads=max-max-threads
Hi,
We are using Tomcat Version : 8.5.53.
OS Name:Linux
OS Version: 3.10.0-1127.18.2.el7.x86_64
We have a requirement where we wanted a logger to get printed in Catalina.out
when Tomcat reaches it's max thread limit.
We reduced values of properties : minSpareThreads, maxThreads and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 8/27/20 18:14, David wrote:
>> I used the http to 8080 in order to read the Tomcat webmanager
>> stats. I originally had issues with the JVM being too small,
>> running out of memory, CPU spiking, threads maxing out, a
>> On 8/27/20 10:48, David wrote:
> >>>>>>> In the last two weeks I've had two occurrences where a
> >>>>>>> single CentOS 7 production server hosting a public
> >>>>>>> webpage has become unresponsive. The first time, all
&g
7, 2020 at 12:35 PM Christopher Schultz
>>>> wrote:
>>>>>
>>>> David,
>>>>
>>>> On 8/27/20 10:48, David wrote:
>>>>>>> In the last two weeks I've had two occurrences where a
>>>>>>> single CentOS 7 pro
>>
> > David,
> >
> > On 8/27/20 10:48, David wrote:
> >>>> In the last two weeks I've had two occurrences where a
> >>>> single CentOS 7 production server hosting a public webpage
> >>>> has become unresponsive. The first time, a
le
>>> CentOS 7 production server hosting a public webpage has become
>>> unresponsive. The first time, all 300 available
>>> "https-jsse-nio-8443" threads were consumed, with the max age
>>> being around 45minutes, and all in a "S" status. This
gt;>> single CentOS 7 production server hosting a public webpage
>>>> has become unresponsive. The first time, all 300 available
>>>> "https-jsse-nio-8443" threads were consumed, with the max age
>>>> being around 45minutes, and all in a "
0 available
> > "https-jsse-nio-8443" threads were consumed, with the max age being
> > around 45minutes, and all in a "S" status. This time all 300 were
> > consumed in "S" status with the oldest being around ~16minutes. A
> > restart of Tomcat
On 27/08/2020 18:57, David wrote:
> On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
> wrote:
>>>> Is there a graceful way to script the termination of threads in
>>>> case Tomcat isn't able to for whatever reason?
>
> Not really.
What you can do is tak
sting a public webpage has become
> > unresponsive. The first time, all 300 available
> > "https-jsse-nio-8443" threads were consumed, with the max age being
> > around 45minutes, and all in a "S" status. This time all 300 were
> > consumed in "S" st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 8/27/20 10:48, David wrote:
> In the last two weeks I've had two occurrences where a single
> CentOS 7 production server hosting a public webpage has become
> unresponsive. The first time, all 300 available
> "https-jsse-
In the last two weeks I've had two occurrences where a single CentOS 7
production server hosting a public webpage has become unresponsive. The
first time, all 300 available "https-jsse-nio-8443" threads were consumed,
with the max age being around 45minutes, and all in a "S&quo
On 14/07/2020 21:08, Mark Thomas wrote:
> On 14/07/2020 20:57, Sridhar Rao wrote:
>>
>> We notice a behavior with tomcat where it becomes unresponsive and all
>> http threads go into a timed wait state and the node becomes unresponsive.
>>
>> Tomcat
On 14/07/2020 20:57, Sridhar Rao wrote:
>
> We notice a behavior with tomcat where it becomes unresponsive and all
> http threads go into a timed wait state and the node becomes unresponsive.
>
> Tomcat Version: 8.5.47
> Could this be a tomcat defect?
Possibly.
Let me ta
ackets in between that is marked as RED in wireshark.
>
> Okay, so far you have told us:
>
> 1. You are using Tomcat 8.5.29
>> [Raghav] yes correct.
> 2. You have an with 450 threads in it
>> [Raghav] Executor has 450 threads.
>
> 3. You see "lots of threads"
&
ing Tomcat 8.5.29
[Raghav] yes correct.
2. You have an with 450 threads in it
[Raghav] Executor has 450 threads.
3. You see "lots of threads"
[Raghav] Yes above 450 threads or all the. 450 threads are alive.
4. You are seeing lots of RST packets.
[Raghav]I can provide one sna
ST packets
> in between that is marked as RED in wireshark.
Okay, so far you have told us:
1. You are using Tomcat 8.5.29
2. You have an with 450 threads in it
3. You see "lots of threads"
4. You are seeing lots of RST packets
We can't help you without more details. Pretend we are
iman (rabhiman) wrote:
> Yes you are correct apache tomcat version 8.5.29 being used.
>
> On 29/04/20, 7:22 PM, "Ragavendhiran Bhiman (rabhiman)"
wrote:
>
> Hi Mark,
>
> We have configured 450 threads for port number 443 with the
On 29/04/2020 14:53, Ragavendhiran Bhiman (rabhiman) wrote:
> Yes you are correct apache tomcat version 8.5.29 being used.
>
> On 29/04/20, 7:22 PM, "Ragavendhiran Bhiman (rabhiman)"
> wrote:
>
> Hi Mark,
>
> We have configured 450 threads for
Yes you are correct apache tomcat version 8.5.29 being used.
On 29/04/20, 7:22 PM, "Ragavendhiran Bhiman (rabhiman)"
wrote:
Hi Mark,
We have configured 450 threads for port number 443 with the following
executer
I could see 450 threads open for
Hi Mark,
We have configured 450 threads for port number 443 with the following executer
I could see 450 threads open for servicing the clients in one specific setup
only what could be the reason?
Thanks a lot.
Regards,
Raghav
On 29/04/20, 7:18
dor and version being used as well
as OS.
> Hi,
>
> I am seeing too many open threads to port number 443 with TLSv1.2, what could
> be the primary reason for the same?
Open threads? That doesn't make sense. Do you mean open ports, threads
(idle, active, both) or something else?
How a
Apache version 8.5.29
From: "Ragavendhiran Bhiman (rabhiman)"
Date: Wednesday, 29 April 2020 at 6:50 PM
To: "users-ow...@tomcat.apache.org" ,
"users@tomcat.apache.org"
Subject: Re: Some questions regarding the TLS1.2 port 443 continuously
communicating and too ma
Adding tomcat users as well.
From: "Ragavendhiran Bhiman (rabhiman)"
Date: Wednesday, 29 April 2020 at 6:45 PM
To: "users-ow...@tomcat.apache.org"
Subject: Some questions regarding the TLS1.2 port 443 continuously
communicating and too many open threads
Hi,
I am seeing t
1.8.0_192-b12,
Windows Server 2012 R2 and at Complete Server Status page I
can see list of all http-nio threads and I can see a header
of ajp-nio threads. But there is displayed only a label Max
threads: and nothing more.
In the localhost.log is an exception: 04-Dec-2018
10:31:38.109 SEVERE [96
>>>> Windows Server 2012 R2 and at Complete Server Status page I
>>>> can see list of all http-nio threads and I can see a header
>>>> of ajp-nio threads. But there is displayed only a label Max
>>>> threads: and nothing more.
>>>&g
threads and I can see a header of ajp-nio threads. But
there is displayed only a label Max threads: and nothing more.
In the localhost.log is an exception: 04-Dec-2018 10:31:38.109
SEVERE [96] org.apache.catalina.core.StandardHostValve.invoke
Exception Processing null
On 04/12/2018 15:10, Jan Vávra wrote:
> Hello,
> I'm using Apache Tomcat/8.5.35, jvm 1.8.0_192-b12, Windows Server 2012
> R2 and at Complete Server Status page I can see list of all http-nio
> threads and I can see a header of ajp-nio threads. But there is
> displayed only a la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jan,
On 12/4/18 10:10, Jan Vávra wrote:
> Hello, I'm using Apache Tomcat/8.5.35, jvm 1.8.0_192-b12, Windows
> Server 2012 R2 and at Complete Server Status page I can see list of
> all http-nio threads and I can see a header of ajp-ni
Hello,
I'm using Apache Tomcat/8.5.35, jvm 1.8.0_192-b12, Windows Server 2012
R2 and at Complete Server Status page I can see list of all http-nio
threads and I can see a header of ajp-nio threads. But there is
displayed only a label Max threads:
and nothing more.
In the localhost.log
On 04/10/18 01:08, Behrooz Nobakht wrote:
> [1] uses a time based threshold to mark a request thread as "stuck" above
> the configured threshold.
>
> This is definitely useful, but maybe a thread is busy transferring a large
> request (IO). This could become
> a wrong conclusion for the thread to
[1] uses a time based threshold to mark a request thread as "stuck" above
the configured threshold.
This is definitely useful, but maybe a thread is busy transferring a large
request (IO). This could become
a wrong conclusion for the thread to be marked as stuck.
A relevant contextual example is
service calls
>>> to initialize. I was making them sequentially with no issues.
>>> I then changed to give them all separate threads so they could
>>> load asynchronously. Then the bottom fell out. I started
>>> getting empty responses and some responses with resul
all separate threads so they could load
asynchronously. Then the bottom fell out. I started getting empty
responses and some responses with results of three or four of the
calls concatenated. I traced the problem from the app back through
apache through mod_jk and found the culprit to be Tomcat
> From: Jerry Malcolm [mailto:techst...@malcolms.com]
> Subject: Re: Servlet Threads Changing Instance Data
> I'm not sure what you mean by typically there is only one servlet
> object. There's one class. But a new instance is created on each
> request, right?
No - there's on
On 8/15/2018 1:50 PM, Olaf Kock wrote:
Jerry,
On 15.08.2018 18:14, Jerry Malcolm wrote:
I have a mobile app that issues several http web service calls to
initialize. I was making them sequentially with no issues. I then
changed to give them all separate threads so they could load
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jerry,
On 8/15/18 12:14 PM, Jerry Malcolm wrote:
> I have a mobile app that issues several http web service calls to
> initialize. I was making them sequentially with no issues. I
> then changed to give them all separate threads so t
Jerry,
On 15.08.2018 18:14, Jerry Malcolm wrote:
I have a mobile app that issues several http web service calls to
initialize. I was making them sequentially with no issues. I then
changed to give them all separate threads so they could load
asynchronously. Then the bottom fell out. I
I have a mobile app that issues several http web service calls to
initialize. I was making them sequentially with no issues. I then
changed to give them all separate threads so they could load
asynchronously. Then the bottom fell out. I started getting empty
responses and some responses
n] org.apache.coyote.AbstractProtocol.start
> Starting ProtocolHandler ["http-nio-auto-1-46276"]
> 17-Nov-2017 19:13:21.796 INFO [main] org.apache.coyote.AbstractProtocol.start
> Starting ProtocolHandler ["http-nio2-8443"]
> 17-Nov-2017 19:13:21.797 INFO [main] o
ctProtocol.start
> Starting ProtocolHandler ["http-nio-auto-1-46276"]
> 17-Nov-2017 19:13:21.796 INFO [main] org.apache.coyote.AbstractProtocol.start
> Starting ProtocolHandler ["http-nio2-8443"]
> 17-Nov-2017 19:13:21.797 INFO [main] org.apache.coyote.AbstractProtoco
I look at the connector thread pool, it creates a set of threads
with this name pattern - "http-nio-auto-1-exec-" - in addition to the
two thread pools used by NIO2 and AJP connectors.
So, the question - What is this so-called "auto" connector for? And why is
Tomcat creatin
HTTP connection (or TCP; the application
> > protocol isn't terribly relevant), then you are limited by the
> > following:
> >
> > 1. Network bandwidth 2. Available threads (to service a particular
> > request) 3. Hardware resources on the server
> > (CPU/me
e (whatever it may
>>>> be).
>
> If the channel is an HTTP connection (or TCP; the application
> protocol isn't terribly relevant), then you are limited by the
> following:
>
> 1. Network bandwidth 2. Available threads (to service a particular
> request) 3. Hardw
lication protocol
> isn't terribly relevant), then you are limited by the following:
>
> 1. Network bandwidth
> 2. Available threads (to service a particular request)
> 3. Hardware resources on the server (CPU/memory/disk/etc.)
>
> Let's ignore 1 and 3 for now, since you are prim
e CHANNEL for
> communicating the resource (whatever it may be).
If the channel is an HTTP connection (or TCP; the application protocol
isn't terribly relevant), then you are limited by the following:
1. Network bandwidth
2. Available threads (to service a particular request)
3. Hardware resources on the
> On 12/08/17 06:00, Christopher Schultz wrote:
> >>>>>> Owen,
> >>>>>>
> >>>>>> Please do not top-post. I have re-ordered your post to
> >>>>>> be bottom-post.
> >>>>>>
> >>>>
dered your post to
>>>>>> be bottom-post.
>>>>>>
>>>>>> On 8/11/17 10:12 PM, Owen Rubel wrote:
>>>>>>> On Fri, Aug 11, 2017 at 5:58 PM,
>>>>>>> <christop...@baus.net> wrote:
>>>>>>
>
17 10:12 PM, Owen Rubel wrote:
> >>>> On Fri, Aug 11, 2017 at 5:58 PM, <christop...@baus.net>
> >>>> wrote:
> >>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I'm looking for a way (or a tool) in Tomcat to associa
17 10:12 PM, Owen Rubel wrote:
> >>>> On Fri, Aug 11, 2017 at 5:58 PM, <christop...@baus.net>
> >>>> wrote:
> >>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I'm looking for a way (or a tool) in Tomcat to associa
ase do not top-post. I have re-ordered your post to be
>>> bottom-post.
>>>
>>> On 8/11/17 10:12 PM, Owen Rubel wrote:
>>>> On Fri, Aug 11, 2017 at 5:58 PM, <christop...@baus.net>
>>>> wrote:
>>>
>>>>>> Hi All,
>>&
;>> Hi All,
> >>>>
> >>>> I'm looking for a way (or a tool) in Tomcat to associate
> >>>> threads with endpoints.
> >>>
> >>> It isn't clear to me why this would be necessary. Threads should
> >>> be allocated on demand
>>>>
>>>> I'm looking for a way (or a tool) in Tomcat to associate
>>>> threads with endpoints.
>>>
>>> It isn't clear to me why this would be necessary. Threads should
>>> be allocated on demand to individual requests. If one route
t;> I'm looking for a way (or a tool) in Tomcat to associate
>>> threads with endpoints.
>>
>> It isn't clear to me why this would be necessary. Threads should
>> be allocated on demand to individual requests. If one route sees
>> more traffic, then it should aut
Absolutely but it could ramp up more threads as needed.
I base the logic on neuron and neuralTransmitters. When neurons talk to
each other, they send back neural transmitters to enforce that pathway.
If we could do the same through threads by adding additional threads for
endpoints that receive
> Hi All,
>
> I'm looking for a way (or a tool) in Tomcat to associate threads with
> endpoints.
It isn't clear to me why this would be necessary. Threads should be
allocated on demand to individual requests. If one route sees more
traffic, then it should automatically be allocated
Hi All,
I'm looking for a way (or a tool) in Tomcat to associate threads with
endpoints.
The reason being is that on a whole, threads are used not by the whole
system but distributed dynamically to specific pieces. Tomcat repeats this
process over and over but never stores this knowledge
On 04/05/17 16:42, Jain Shailu wrote:
> We have updated the maxThread configuration to 10 at below place in
> server.xml of DEV environment. However I was able to see more than 10
> threads. I have also attached the server.xml
>
>
> I need your help to understand if I am doi
We have updated the maxThread configuration to 10 at below place in
server.xml of DEV environment. However I was able to see more than 10
threads. I have also attached the server.xml
I need your help to understand if I am doing something wrong or it is
an expected behaviour?
A "Conn
On 11/04/17 13:35, Johan Compagner wrote:
> Thread: http-443-72, state: RUNNABLE, total cpu time: 5583984.375ms, total
> user time: 5451312.5ms
> java.net.SocketInputStream.socketRead0(Native Method)
> java.net.SocketInputStream.socketRead(Unknown Source)
>
Thread: http-443-72, state: RUNNABLE, total cpu time: 5583984.375ms, total
user time: 5451312.5ms
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.socketRead(Unknown Source)
java.net.SocketInputStream.read(Unknown Source)
1b2d4e0fea7cb0f7a9d3
> c>
> >>>>>
> >>>>>>
> >
> >
> d1e750b48498ff2
> >>>>
> >>>> That was pretty much what I was thinking.
> >
> >
> >> If you want it, let me know. I can provide
> https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7
a9d
>
>>>>>>
3c
> <https://github.com/johnament/tomcat85/commit/a0281b2d4e0fea7cb0f7a9d3
c>
>>>>>
>>>>>>
>
>
d1e750b48498ff2
>>>>
>>>>
1 - 100 of 1077 matches
Mail list logo
