-9.0-doc/api/org/apache/tomcat/util/threads/RetryableQueue.html
Removed:
tomcat/site/trunk/docs/tomcat-9.0-doc/api/org/apache/tomcat/util/http/fileupload/util/mime/RFC2231Utility.html
Added:
tomcat/site/trunk/docs/tomcat-9.0-doc/api/org/apache/catalina/valves/ParameterLimitValve.html
URL:
galkin-anton closed pull request #866: add set flag for use virtual threads by
connector
URL: https://github.com/apache/tomcat/pull/866
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific
galkin-anton commented on PR #866:
URL: https://github.com/apache/tomcat/pull/866#issuecomment-2956356313
Thank you for your advice. Then I reject pull request
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL ab
markt-asf commented on PR #866:
URL: https://github.com/apache/tomcat/pull/866#issuecomment-2956270535
If you want to set that property, use the `setProperty(String,String)`
method. There are a lot of properties that are just passed through from the
`Connector` to the `Endpoint`. Those prop
galkin-anton commented on PR #866:
URL: https://github.com/apache/tomcat/pull/866#issuecomment-2956256549
With this flag, the executor will be created in
org.apache.tomcat.util.net.AbstractEndpoint#createExecutor
--
This is an automated message from the Apache Git Service.
To respond to t
galkin-anton commented on PR #866:
URL: https://github.com/apache/tomcat/pull/866#issuecomment-2956249452
I thought this patch would be useful to everyone
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above t
#x27;d like to manage the ability to use virtual threads through
property along with the VirtualExecutor setting. In addition, AbstractEndpoint
has a setUseVirtualThreads method. I apologize for the semi-colon.
--
This is an automated message from the Apache Git Service.
To respond to the message,
markt-asf commented on PR #866:
URL: https://github.com/apache/tomcat/pull/866#issuecomment-2956213892
What is the purpose of this change? It does not appear to be necessary.
Further, the patch as provided includes an unnecessary semi-colon.
--
This is an automated message from the
galkin-anton opened a new pull request, #866:
URL: https://github.com/apache/tomcat/pull/866
(no comment)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #20 from Ronny Perinke ---
To me, it sounds like it's time to say goodbye to NIO2.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #19 from Remy Maucherat ---
NIO2 is very clean, so initially when it was released it was better than NIO,
which felt abandoned.
Since then, roughly staring with Java 11, the following happened:
- NIO got fixes and significant refac
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #18 from Mark Thomas ---
NIO is poller based.
NIO2 is callback based.
Performance wise they should be pretty much identical.
--
You are receiving this mail because:
You are the assignee for the bug.
--
NIO2? We have been using
NIO2 for many years without virtual threads and have not noticed any
NIO2-related problems. The comparison table
(https://tomcat.apache.org/tomcat-11.0-doc/config/http.html#Connector_Comparison)
is not very helpful as it does not show any significant differences.
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #16 from sephir...@sephiroth-j.de ---
The problem still exists if openssl and tcnative for RHEL 9 are built with the
same image that is used as the base image for the application container.
--
You are receiving this mail because:
Y
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #15 from sephir...@sephiroth-j.de ---
Created attachment 40028
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40028&action=edit
Dockerfile to build tcnative for rhel9
I have added a Dockerfile to create openssl and tcnative
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
sephir...@sephiroth-j.de changed:
What|Removed |Added
Attachment #40021|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #13 from Mark Thomas ---
Thanks for the test case.
I've just run a test with wrk and HTTP keep-alive disabled using a single
thread making ~750 req/s for 5 minutes without any occurrence of this error on
both the Temurin and the Zu
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
sephir...@sephiroth-j.de changed:
What|Removed |Added
Attachment #40026|Dynatrace: requests with|Dynatrace: requests with
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
sephir...@sephiroth-j.de changed:
What|Removed |Added
Attachment #40026|Dynatrace: requests with|Dynatrace: requests with
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #12 from sephir...@sephiroth-j.de ---
Created attachment 40026
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40026&action=edit
Dynatrace: requests with exception 2025-04-25
--
You are receiving this mail because:
You are t
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #9 from sephir...@sephiroth-j.de ---
Created attachment 40023
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40023&action=edit
Dynatrace: request with exception code level
--
You are receiving this mail because:
You are the
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #11 from sephir...@sephiroth-j.de ---
Created attachment 40025
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40025&action=edit
Dynatrace: request without exception timing
--
You are receiving this mail because:
You are the
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #8 from sephir...@sephiroth-j.de ---
Created attachment 40022
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40022&action=edit
Dynatrace: request with exception 2 threads
--
You are receiving this mail because:
You
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #10 from sephir...@sephiroth-j.de ---
Created attachment 40024
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40024&action=edit
Dynatrace: request with exception timing
--
You are receiving this mail because:
You are the as
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #7 from sephir...@sephiroth-j.de ---
Created attachment 40021
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40021&action=edit
sample soap-service app
A sample app to deploy. The error should occur when making an HTTP GET re
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #6 from sephir...@sephiroth-j.de ---
I have checked the logs in Splunk and Dynatrace. As suspected, the timestamps
from Splunk match the check requests from Kubernetes to the servlet endpoint.
According to Dynatrace, the request alwa
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #5 from Mark Thomas ---
Just a reminder that without sufficient information provided that enables this
issue to be reproduced, this issue will eventually be resolved as WORKSFORME.
Given you can reproduce the issue, a few things to
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #4 from Remy Maucherat ---
Maybe you should simply not use virtual threads with NIO2, this is basically
untested.
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #3 from sephir...@sephiroth-j.de ---
The affected application is a jax-ws Soap service and I think the exception
occurs when opening the endpoint servlet (that one showing the endpoint classes
and wsdl, com.sun.xml.ws.transport.http.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Mark Thomas
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
--- Comment #1 from Mark Thomas ---
Do you notice any application or client issues when you see this exception?
Do you have any indications of what sort of requests are being processed
(response size, static/dynamic content, HTTP/WebSocket) wh
https://bz.apache.org/bugzilla/show_bug.cgi?id=69631
Bug ID: 69631
Summary: java.nio.channels.WritePendingException when using
https-openssl-nio2 and virtual threads
Product: Tomcat 11
Version: unspecified
Hardware: PC
threads
b4869918e6 is described below
commit b4869918e630aec1ca524c603037c9a8eadfc770
Author: Mark Thomas
AuthorDate: Mon Feb 3 10:02:03 2025 +
Limit maximum memory to 256m for test threads
I was observing OOME with runs using a large number of threads on a
machine with lots
threads
65236d77ab is described below
commit 65236d77ab9de51941eff6153ed75f173572f9ac
Author: Mark Thomas
AuthorDate: Mon Feb 3 10:02:03 2025 +
Limit maximum memory to 256m for test threads
I was observing OOME with runs using a large number of threads on a
machine with lots
threads
9414daabec is described below
commit 9414daabec00552faad41bd6c2dcda3403945e97
Author: Mark Thomas
AuthorDate: Mon Feb 3 10:02:03 2025 +
Limit maximum memory to 256m for test threads
I was observing OOME with runs using a large number of threads on a
machine with lots
threads
1dbe55ee39 is described below
commit 1dbe55ee39f1a7b14effea46c7be1be7cb3d23b6
Author: Mark Thomas
AuthorDate: Mon Feb 3 10:02:03 2025 +
Limit maximum memory to 256m for test threads
I was observing OOME with runs using a large number of threads on a
machine with lots of
Mark,
On 10/21/24 11:42, Mark Thomas wrote:
Spinning off this specific topic.
On 08/10/2024 13:25, Rémy Maucherat wrote:
On Tue, Oct 8, 2024 at 7:51 AM Christopher Schultz
wrote:
In the pub track at the end of the day, I proposed bringing back the BIO
connector with Virtual Threads as the
bringing back the BIO
> >> connector with Virtual Threads as the magic which makes everything work.
> >> markt is convinced the idea has merit and on initial hand-waving
> >> conversation, he thinks that maybe just maybe Tomcat 12 could dump both
> >> NIO and NI
Spinning off this specific topic.
On 08/10/2024 13:25, Rémy Maucherat wrote:
On Tue, Oct 8, 2024 at 7:51 AM Christopher Schultz
wrote:
In the pub track at the end of the day, I proposed bringing back the BIO
connector with Virtual Threads as the magic which makes everything work.
markt is
https://bz.apache.org/bugzilla/show_bug.cgi?id=68868
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=68868
Naman changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://bz.apache.org/bugzilla/show_bug.cgi?id=68868
Mark Thomas changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=68868
Bug ID: 68868
Summary: Log rotation in a Spring Boot application leaves
threads in timed_waiting state
Product: Tomcat 10
Version: unspecified
Hardware: PC
Romain,
On 3/20/24 16:25, Romain Manni-Bucau wrote:
Chris, added some comments inline.
Le mer. 20 mars 2024 à 19:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
Romain,
On 3/20/24 13:34, Romain Manni-Bucau wrote:
Thread dumps being dump of threads - literally os t
Chris, added some comments inline.
Le mer. 20 mars 2024 à 19:41, Christopher Schultz <
ch...@christopherschultz.net> a écrit :
> Romain,
>
> On 3/20/24 13:34, Romain Manni-Bucau wrote:
> > Thread dumps being dump of threads - literally os threads - and virtual
> > t
Am 20.03.24 um 18:50 schrieb Romain Manni-Bucau:
Le mer. 20 mars 2024 à 18:43, Rainer Jung a
écrit :
Am 20.03.24 um 18:34 schrieb Romain Manni-Bucau:
Hi Chris,
Thread dumps being dump of threads - literally os threads - and virtual
threads not being threads at all - they are runnables in a
Romain,
On 3/20/24 13:34, Romain Manni-Bucau wrote:
Thread dumps being dump of threads - literally os threads - and virtual
threads not being threads at all - they are runnables in a dedicated thread
pool - it is quite fair to not make them the same and have their scheduler
- pool - only in the
improved and I am
not aware of it, hints welcome.
Part of JEP 425 (Project Loom, Java virtual threads) discusses how to
handle observability of virtual threads from inside the JVM and tooling.
The final outcome is, that virtual threads are not included in the
typical JVM APIs which one can use to
Le mer. 20 mars 2024 à 18:43, Rainer Jung a
écrit :
> Am 20.03.24 um 18:34 schrieb Romain Manni-Bucau:
> > Hi Chris,
> >
> > Thread dumps being dump of threads - literally os threads - and virtual
> > threads not being threads at all - they are runnables in a dedicate
Am 20.03.24 um 18:34 schrieb Romain Manni-Bucau:
Hi Chris,
Thread dumps being dump of threads - literally os threads - and virtual
threads not being threads at all - they are runnables in a dedicated thread
pool - it is quite fair to not make them the same and have their scheduler
- pool - only
Hi Chris,
Thread dumps being dump of threads - literally os threads - and virtual
threads not being threads at all - they are runnables in a dedicated thread
pool - it is quite fair to not make them the same and have their scheduler
- pool - only in the thread dump but not themselves no
.
Part of JEP 425 (Project Loom, Java virtual threads) discusses how to
handle observability of virtual threads from inside the JVM and tooling.
The final outcome is, that virtual threads are not included in the
typical JVM APIs which one can use to observe threads, like
enumerating them or
threads) discusses how to
handle observability of virtual threads from inside the JVM and tooling.
The final outcome is, that virtual threads are not included in the
typical JVM APIs which one can use to observe threads, like enumerating
them or accessing the stacks of individual threads. As a
Romain Manni-Bucau:
Hi Rainer,
Think this is not related to virtual threads I think and way older (2010?).
Since some years we use AsyncContext and therefore thread dumps don't match
pending requests but just active computation (you can get 8K requests with
8 threads for ex).
Most of the
Hi Rainer,
Think this is not related to virtual threads I think and way older (2010?).
Since some years we use AsyncContext and therefore thread dumps don't match
pending requests but just active computation (you can get 8K requests with
8 threads for ex).
Most of the sync instrument
Hi hi,
I wanted to share an observation and I hope the things are correct how I
am describing them. Maybe things have already improved and I am not
aware of it, hints welcome.
Part of JEP 425 (Project Loom, Java virtual threads) discusses how to
handle observability of virtual threads from
s the so-called Virtual Threads "pinning"
issue.
[1] https://openjdk.org/projects/jdk/22/
[2] https://openjdk.org/jeps/455
[3] https://openjdk.org/jeps/465
[4] https://openjdk.org/jeps/466
## Heads-up: Virtual Threads “Pinning” Issue
Virtual threads became a permanent feature in JDK
lready provided feedback on the JDK 22
EA builds. Feedback is always extremely useful, even more, when it comes early
in the development cycle. Another area where we need your help is Loom. So,
please make sure to check the heads-up below that discusses the so-called
Virtual Threads "pinnin
please find attached sample
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=68312
--- Comment #3 from Christopher Schultz ---
And Tomcat 10.1: 2b3f0f09641e0d8504a114cf296a18d66039266b will be in 10.1.18
--
You are receiving this mail because:
You are the assignee for the bug.
---
> The following commit(s) were added to refs/heads/main by this push:
> > new f9fb4f443d Fix NIO2 and virtual threads (NIO2 requires
> > ExecutorService)
> > f9fb4f443d is described below
> >
> > commit f9fb4f443d5c6814445a42174288ae549abc83ec
> > Author:
://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new f9fb4f443d Fix NIO2 and virtual threads (NIO2 requires
ExecutorService)
f9fb4f443d is described below
commit f9fb4f443d5c6814445a42174288ae549abc83ec
Author: Mark Thomas
AuthorDate: Fri
https://bz.apache.org/bugzilla/show_bug.cgi?id=68312
Christopher Schultz changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=68312
Christopher Schultz changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVA
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new bf1a093b63 Fix NIO2 and virtual threads (NIO2
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 81ff43e1e7 Fix NIO2 and virtual threads (NIO2
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new f9fb4f443d Fix NIO2 and virtual threads (NIO2
https://bz.apache.org/bugzilla/show_bug.cgi?id=68312
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=68312
Nicolas changed:
What|Removed |Added
OS||All
--
You are receiving this mail because:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68312
Bug ID: 68312
Summary: Virtual threads with Http11Nio2Protocol
Product: Tomcat 10
Version: 10.1.16
Hardware: Macintosh
Status: NEW
Severity: normal
Priority
code when using
virtual threads
10af915c7e is described below
commit 10af915c7e191b7d4a4b3691217f937ee2c4b1a7
Author: Mark Thomas
AuthorDate: Thu Jul 27 15:37:59 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2
code when using
virtual threads
dc8f0d1b3c is described below
commit dc8f0d1b3c3d50caf84ee60b3a487928216ea432
Author: Mark Thomas
AuthorDate: Thu Jul 27 15:37:59 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2
code when using
virtual threads
e633e73d61 is described below
commit e633e73d616196fa26da69458fca26b31c5d436a
Author: Mark Thomas
AuthorDate: Thu Jul 27 15:37:59 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2
when using
virtual threads
762eb130a8 is described below
commit 762eb130a8608c18375a84276323f7cb65f7333a
Author: Mark Thomas
AuthorDate: Thu Jul 27 15:37:59 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/AbstractStream.java
code when using
virtual threads
b11e591da4 is described below
commit b11e591da4e57c4d9520a91fc5f6024cb7be3278
Author: Mark Thomas
AuthorDate: Wed Jul 26 14:12:50 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java | 90
code when using
virtual threads
e74bda808a is described below
commit e74bda808aa043b09790135f53d7de692cc3e1c3
Author: Mark Thomas
AuthorDate: Wed Jul 26 14:38:37 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java | 90
code when using
virtual threads
24b8501020 is described below
commit 24b8501020eac62dbfe6957887aa8c2e1e0f803d
Author: Mark Thomas
AuthorDate: Wed Jul 26 14:38:37 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java | 90
when using
virtual threads
0338f2b113 is described below
commit 0338f2b113295482bacd9ef57264987cb4502f0e
Author: Mark Thomas
AuthorDate: Wed Jul 26 14:38:37 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java | 90
code when using
virtual threads
50f627546f is described below
commit 50f627546f085ae64aff4c3e4465d4cd797a685c
Author: Mark Thomas
AuthorDate: Wed Jul 26 13:23:39 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
.../apache/coyote/http2
code when using
virtual threads
905e6bbd47 is described below
commit 905e6bbd47cc6d80d787ee833c5697f0a9f7f532
Author: Mark Thomas
AuthorDate: Wed Jul 26 13:23:39 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
.../apache/coyote/http2
when using
virtual threads
fa7f17b010 is described below
commit fa7f17b010057a1ea007cbd810c147baac95d000
Author: Mark Thomas
AuthorDate: Wed Jul 26 13:23:39 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
.../apache/coyote/http2
code when using
virtual threads
259c615a76 is described below
commit 259c615a764ce90a08e9a09c31f49379ce1cdb8b
Author: Mark Thomas
AuthorDate: Wed Jul 26 12:36:15 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java | 295
code when using
virtual threads
d48c941249 is described below
commit d48c941249d51dd486735321b84a734b5de06af0
Author: Mark Thomas
AuthorDate: Wed Jul 26 12:36:15 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java
when using
virtual threads
36e8fd9033 is described below
commit 36e8fd9033ccc26e63667e6a75a6b213df9cfe9c
Author: Mark Thomas
AuthorDate: Wed Jul 26 12:36:15 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java | 244
code when using
virtual threads
acf7bc0d20 is described below
commit acf7bc0d20954f809cf2fb7a13afb6372d82f1f4
Author: Mark Thomas
AuthorDate: Wed Jul 26 12:36:15 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2/Stream.java | 244
code when using
virtual threads
8044fc73b4 is described below
commit 8044fc73b4e987d8e75a199dcdc907155dd0f6eb
Author: Mark Thomas
AuthorDate: Wed Jul 26 10:34:38 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2
code when using
virtual threads
10443575cf is described below
commit 10443575cfa1740e72002ac28281d4ea3b3af24c
Author: Mark Thomas
AuthorDate: Wed Jul 26 10:34:38 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2
code when using
virtual threads
56ba62e2fc is described below
commit 56ba62e2fc60c550a8b90a54452f78683a682ea0
Author: Mark Thomas
AuthorDate: Wed Jul 26 10:34:38 2023 +0100
Refactor to reduce pinning in HTTP/2 code when using virtual threads
---
java/org/apache/coyote/http2
Hi all,
Following a report on the users list [1], I am currently looking at
various refactoring to reduce pinning when using virtual threads. The
process I am following is:
- configure unit tests to run with virtual threads and pinning debug
logging
- run the Tomcat 11 test suite
- use
https://bz.apache.org/bugzilla/show_bug.cgi?id=60918
--- Comment #13 from yangshj ---
Who can provide the test code for the recurrence of this bug
--
You are receiving this mail because:
You are the assignee for the bug.
-
To u
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #22 from Mark Thomas ---
Thanks for confirming the fix.
Generally, if applications simulate blocking using non-blocking I/O that will
be problematic.
If there is a way to reduce the locking in Tomcat (and hence reduce the chances
to be a regression introduced
in 9.0.74.
In the past, after upgrading CometD from 3 to 5 with Tomcat version 9.0.63 we
noticed all the HTTP-nio2 threads blocked without making progress. We raised
the issue with CometD https://github.com/cometd/cometd/issues/1328
and Tomcat https://bz.apache.org
virtual threads
b2f2002bbf is described below
commit b2f2002bbf282d446ef55817ca3fc7f36d144330
Author: Mark Thomas
AuthorDate: Mon May 22 13:51:48 2023 +0100
Use consistent default naming for virtual threads
---
java/org/apache/tomcat/util/net/AbstractEndpoint.java | 2 +-
1 file changed, 1
virtual threads
1face8c2b1 is described below
commit 1face8c2b16f67dcc7a6800e8506032818b25359
Author: Mark Thomas
AuthorDate: Mon May 22 13:51:48 2023 +0100
Use consistent default naming for virtual threads
---
java/org/apache/tomcat/util/net/AbstractEndpoint.java | 2 +-
1 file changed, 1
virtual threads
a8e4e0e566 is described below
commit a8e4e0e566b23a5c7a976dbb211cb2dfce343a5a
Author: Mark Thomas
AuthorDate: Mon May 22 13:51:48 2023 +0100
Use consistent default naming for virtual threads
---
java/org/apache/tomcat/util/net/AbstractEndpoint.java | 2 +-
1 file changed, 1
threads
0d3a24515d is described below
commit 0d3a24515dc8afdb814cbd594411530a2cdabc06
Author: Mark Thomas
AuthorDate: Mon May 22 13:51:48 2023 +0100
Use consistent default naming for virtual threads
---
java/org/apache/tomcat/util/net/AbstractEndpoint.java | 2 +-
1 file changed, 1
prefix for virtual threads and document the default prefixes
---
java/org/apache/catalina/core/StandardVirtualThreadExecutor.java | 2 +-
webapps/docs/config/executor.xml | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/java/org/apache
prefix for virtual threads and document the default prefixes
---
java/org/apache/catalina/core/StandardVirtualThreadExecutor.java | 2 +-
webapps/docs/config/executor.xml | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/java/org/apache
threads and document the
default prefixes
e41bfacace is described below
commit e41bfacaceafcb207c2c98fb8b05e5a4173dcbe4
Author: Mark Thomas
AuthorDate: Sat May 13 13:29:57 2023 +0100
Add default prefix for virtual threads and document the default prefixes
---
java/org/apache/catalina/core
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 345164ed7f Add default prefix for virtual threads
1 - 100 of 610 matches
Mail list logo
