[GitHub] [tomcat] aooohan commented on pull request #559: fix Bug 66318 - Set multiple domain names for one address，In Windows 10 OS. AbstractProcessor.populateRequestAttributeRemoteHost aways get wro
aooohan commented on PR #559: URL: https://github.com/apache/tomcat/pull/559#issuecomment-1286564703 Your commit has nothing to do with your PR title. Also your commit is redundant: https://bz.apache.org/bugzilla/show_bug.cgi?id=66233 -- 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-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] aooohan closed pull request #559: fix Bug 66318 - Set multiple domain names for one address，In Windows 10 OS. AbstractProcessor.populateRequestAttributeRemoteHost aways get wrong hos
aooohan closed pull request #559: fix Bug 66318 - Set multiple domain names for one address，In Windows 10 OS. AbstractProcessor.populateRequestAttributeRemoteHost aways get wrong host URL: https://github.com/apache/tomcat/pull/559 -- 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-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Fix some deprecation warnings when building with newer versions of Java
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 fea617de08 Fix some deprecation warnings when building with newer
versions of Java
fea617de08 is described below
commit fea617de08f32d098fae5be21a8bb097a514f729
Author: Mark Thomas
AuthorDate: Fri Oct 21 09:31:29 2022 +0100
Fix some deprecation warnings when building with newer versions of Java
---
test/org/apache/catalina/connector/TestResponse.java | 2 +-
test/org/apache/tomcat/util/res/TestStringManager.java | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/test/org/apache/catalina/connector/TestResponse.java
b/test/org/apache/catalina/connector/TestResponse.java
index b4924921c0..73ee4674f1 100644
--- a/test/org/apache/catalina/connector/TestResponse.java
+++ b/test/org/apache/catalina/connector/TestResponse.java
@@ -645,7 +645,7 @@ public class TestResponse extends TomcatBaseTest {
private static final String TEXT_ISO_8859_1 = TEXT + ";charset=" +
ISO_8859_1;
private static final String TEXT_UTF_8 = TEXT + ";charset=" + UTF_8;
private static final String TEXT_UNKNOWN = TEXT + ";charset=" + UNKNOWN;
-private static final Locale UNDETERMINED = new Locale("und");
+private static final Locale UNDETERMINED = Locale.forLanguageTag("xxx");
@Test
public void testSetCharacterEncoding01() {
diff --git a/test/org/apache/tomcat/util/res/TestStringManager.java
b/test/org/apache/tomcat/util/res/TestStringManager.java
index 4b01db8779..289d3973df 100644
--- a/test/org/apache/tomcat/util/res/TestStringManager.java
+++ b/test/org/apache/tomcat/util/res/TestStringManager.java
@@ -31,8 +31,9 @@ public class TestStringManager {
private static final StringManager sm =
StringManager.getManager(PACKAGE_NAME);
private static final Locale[] ALL_LOCALES = new Locale[] {
-Locale.ENGLISH, new Locale("cs"), Locale.GERMAN, new Locale("es"),
Locale.FRENCH, Locale.JAPANESE,
-Locale.KOREAN, new Locale("pt_BR"), new Locale("ru"),
Locale.SIMPLIFIED_CHINESE };
+Locale.ENGLISH, Locale.forLanguageTag("cs"), Locale.GERMAN,
Locale.forLanguageTag("es"), Locale.FRENCH,
+Locale.JAPANESE, Locale.KOREAN, Locale.forLanguageTag("pt_BR"),
Locale.forLanguageTag("ru"),
+Locale.SIMPLIFIED_CHINESE };
private static final Set CJK_LOCALES;
static {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.1.x updated: Fix some deprecation warnings when building with newer versions of Java
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 1006b3ba4d Fix some deprecation warnings when building with newer
versions of Java
1006b3ba4d is described below
commit 1006b3ba4db03c47b966af1440cd3fb20af6d382
Author: Mark Thomas
AuthorDate: Fri Oct 21 09:31:29 2022 +0100
Fix some deprecation warnings when building with newer versions of Java
---
test/org/apache/catalina/connector/TestResponse.java | 2 +-
test/org/apache/tomcat/util/res/TestStringManager.java | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/test/org/apache/catalina/connector/TestResponse.java
b/test/org/apache/catalina/connector/TestResponse.java
index b4924921c0..73ee4674f1 100644
--- a/test/org/apache/catalina/connector/TestResponse.java
+++ b/test/org/apache/catalina/connector/TestResponse.java
@@ -645,7 +645,7 @@ public class TestResponse extends TomcatBaseTest {
private static final String TEXT_ISO_8859_1 = TEXT + ";charset=" +
ISO_8859_1;
private static final String TEXT_UTF_8 = TEXT + ";charset=" + UTF_8;
private static final String TEXT_UNKNOWN = TEXT + ";charset=" + UNKNOWN;
-private static final Locale UNDETERMINED = new Locale("und");
+private static final Locale UNDETERMINED = Locale.forLanguageTag("xxx");
@Test
public void testSetCharacterEncoding01() {
diff --git a/test/org/apache/tomcat/util/res/TestStringManager.java
b/test/org/apache/tomcat/util/res/TestStringManager.java
index 4b01db8779..289d3973df 100644
--- a/test/org/apache/tomcat/util/res/TestStringManager.java
+++ b/test/org/apache/tomcat/util/res/TestStringManager.java
@@ -31,8 +31,9 @@ public class TestStringManager {
private static final StringManager sm =
StringManager.getManager(PACKAGE_NAME);
private static final Locale[] ALL_LOCALES = new Locale[] {
-Locale.ENGLISH, new Locale("cs"), Locale.GERMAN, new Locale("es"),
Locale.FRENCH, Locale.JAPANESE,
-Locale.KOREAN, new Locale("pt_BR"), new Locale("ru"),
Locale.SIMPLIFIED_CHINESE };
+Locale.ENGLISH, Locale.forLanguageTag("cs"), Locale.GERMAN,
Locale.forLanguageTag("es"), Locale.FRENCH,
+Locale.JAPANESE, Locale.KOREAN, Locale.forLanguageTag("pt_BR"),
Locale.forLanguageTag("ru"),
+Locale.SIMPLIFIED_CHINESE };
private static final Set CJK_LOCALES;
static {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Fix deprecation warning when building with newer versions of Java
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 9572e12ed1 Fix deprecation warning when building with newer versions
of Java
9572e12ed1 is described below
commit 9572e12ed1a11813882ea12b600d499e41f908c1
Author: Mark Thomas
AuthorDate: Fri Oct 21 09:31:29 2022 +0100
Fix deprecation warning when building with newer versions of Java
---
test/org/apache/catalina/connector/TestResponse.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/org/apache/catalina/connector/TestResponse.java
b/test/org/apache/catalina/connector/TestResponse.java
index e114e52dd8..3f451f744a 100644
--- a/test/org/apache/catalina/connector/TestResponse.java
+++ b/test/org/apache/catalina/connector/TestResponse.java
@@ -645,7 +645,7 @@ public class TestResponse extends TomcatBaseTest {
private static final String TEXT_ISO_8859_1 = TEXT + ";charset=" +
ISO_8859_1;
private static final String TEXT_UTF_8 = TEXT + ";charset=" + UTF_8;
private static final String TEXT_UNKNOWN = TEXT + ";charset=" + UNKNOWN;
-private static final Locale UNDETERMINED = new Locale("und");
+private static final Locale UNDETERMINED = Locale.forLanguageTag("xxx");
@Test
public void testSetCharacterEncoding01() {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Fix deprecation warning when building with newer versions of Java
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 f18a816fbd Fix deprecation warning when building with newer versions
of Java
f18a816fbd is described below
commit f18a816fbd763240e7ce2fe15893ebc54ecf843d
Author: Mark Thomas
AuthorDate: Fri Oct 21 09:31:29 2022 +0100
Fix deprecation warning when building with newer versions of Java
---
test/org/apache/catalina/connector/TestResponse.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/org/apache/catalina/connector/TestResponse.java
b/test/org/apache/catalina/connector/TestResponse.java
index 620c532978..14c189c240 100644
--- a/test/org/apache/catalina/connector/TestResponse.java
+++ b/test/org/apache/catalina/connector/TestResponse.java
@@ -646,7 +646,7 @@ public class TestResponse extends TomcatBaseTest {
private static final String TEXT_ISO_8859_1 = TEXT + ";charset=" +
ISO_8859_1;
private static final String TEXT_UTF_8 = TEXT + ";charset=" + UTF_8;
private static final String TEXT_UNKNOWN = TEXT + ";charset=" + UNKNOWN;
-private static final Locale UNDETERMINED = new Locale("und");
+private static final Locale UNDETERMINED = Locale.forLanguageTag("xxx");
@Test
public void testSetCharacterEncoding01() {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch loom created (now 6a22f2f399)
On Thu, Oct 20, 2022 at 3:46 PM Rémy Maucherat wrote: > Ok, that is reasonable and seeing what can be expected in the best > case is a good plan. Async will indeed be a bit more expensive with > Loom, just like blocking is more expensive with NIO(2). I'm starting testing, and it looks like the basics work, as you said. The first item is to identify a best case scenario for Loom. I decided to try with a static file (in the context of Tomcat, a low level API would be very similar in terms of IO), but maybe this is not it and a Servlet doing computations would be better for Loom (with less IO load). Pulling out my good old ab, I have some rather interesting results. -c 1 (no concurrency) is looking awesome for Loom, where it basically destroys NIO. However, it degrades quickly from there. -c 2 is already a lot closer. -c 5 is the inflexion point where NIO pulls ahead. Then as concurrency increases Loom becomes slower. Thankfully, it doesn't degrade too much from there and with high concurrency it remains reasonably close. I don't have a high core count CPU though so this could make for some differences as well. Overall I would say this matches your finding. I tested with my panama-foreign Java "20" build. We should probably wait for the real Java 20 to start making decisions. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] aooohan merged pull request #556: Note that maxHttpHeaderSize always allocates the max size
aooohan merged PR #556: URL: https://github.com/apache/tomcat/pull/556 -- 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-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Note that maxHttpHeaderSize always allocates the max size
This is an automated email from the ASF dual-hosted git repository. lihan 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 cbae167168 Note that maxHttpHeaderSize always allocates the max size cbae167168 is described below commit cbae1671687d29e63d5e2f3cc54f0a24671e0855 Author: Jordan Christiansen AuthorDate: Wed Oct 12 14:08:40 2022 -0500 Note that maxHttpHeaderSize always allocates the max size --- webapps/docs/config/http.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index 61413829cb..306b5e084e 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -525,6 +525,11 @@ the request line, header names and header values. If not specified, this attribute is set to the value of the maxHttpHeaderSize attribute. + If you see "Request header is too large" errors you can increase this, + but be aware that Tomcat will allocate the full amount you specify for + every request. For example, if you specify a maxHttpRequestHeaderSize of + 1 MB and your application handles 100 concurrent requests, you will see + 100 MB of heap consumed by request headers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.1.x updated: Note that maxHttpHeaderSize always allocates the max size
This is an automated email from the ASF dual-hosted git repository. lihan pushed a commit to branch 10.1.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/10.1.x by this push: new 8abea615b7 Note that maxHttpHeaderSize always allocates the max size 8abea615b7 is described below commit 8abea615b7c231a0dd84060a7929e6fbd9ddde9a Author: Jordan Christiansen AuthorDate: Wed Oct 12 14:08:40 2022 -0500 Note that maxHttpHeaderSize always allocates the max size --- webapps/docs/config/http.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index 8b6ace9a42..cf33dff577 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -525,6 +525,11 @@ the request line, header names and header values. If not specified, this attribute is set to the value of the maxHttpHeaderSize attribute. + If you see "Request header is too large" errors you can increase this, + but be aware that Tomcat will allocate the full amount you specify for + every request. For example, if you specify a maxHttpRequestHeaderSize of + 1 MB and your application handles 100 concurrent requests, you will see + 100 MB of heap consumed by request headers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.0.x updated: Note that maxHttpHeaderSize always allocates the max size
This is an automated email from the ASF dual-hosted git repository. lihan pushed a commit to branch 10.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/10.0.x by this push: new efd0ff4ffa Note that maxHttpHeaderSize always allocates the max size efd0ff4ffa is described below commit efd0ff4ffaeee1e5a7459ab064437b4a0bb2a1a5 Author: Jordan Christiansen AuthorDate: Wed Oct 12 14:08:40 2022 -0500 Note that maxHttpHeaderSize always allocates the max size --- webapps/docs/config/http.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index af2911f42c..0e9baf4116 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -535,6 +535,11 @@ the request line, header names and header values. If not specified, this attribute is set to the value of the maxHttpHeaderSize attribute. + If you see "Request header is too large" errors you can increase this, + but be aware that Tomcat will allocate the full amount you specify for + every request. For example, if you specify a maxHttpRequestHeaderSize of + 1 MB and your application handles 100 concurrent requests, you will see + 100 MB of heap consumed by request headers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Note that maxHttpHeaderSize always allocates the max size
This is an automated email from the ASF dual-hosted git repository. lihan 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 70d776a391 Note that maxHttpHeaderSize always allocates the max size 70d776a391 is described below commit 70d776a39105f6a8fcd0c14f376472c155bbe001 Author: Jordan Christiansen AuthorDate: Wed Oct 12 14:08:40 2022 -0500 Note that maxHttpHeaderSize always allocates the max size --- webapps/docs/config/http.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index 8f5501044d..019e859796 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -531,6 +531,11 @@ the request line, header names and header values. If not specified, this attribute is set to the value of the maxHttpHeaderSize attribute. + If you see "Request header is too large" errors you can increase this, + but be aware that Tomcat will allocate the full amount you specify for + every request. For example, if you specify a maxHttpRequestHeaderSize of + 1 MB and your application handles 100 concurrent requests, you will see + 100 MB of heap consumed by request headers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Note that maxHttpHeaderSize always allocates the max size
This is an automated email from the ASF dual-hosted git repository. lihan 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 495149bb46 Note that maxHttpHeaderSize always allocates the max size 495149bb46 is described below commit 495149bb46bf22054ab82a16c9f0004d55792139 Author: Jordan Christiansen AuthorDate: Wed Oct 12 14:08:40 2022 -0500 Note that maxHttpHeaderSize always allocates the max size --- webapps/docs/config/http.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml index 47d0b923bf..ac528d896d 100644 --- a/webapps/docs/config/http.xml +++ b/webapps/docs/config/http.xml @@ -531,6 +531,11 @@ the request line, header names and header values. If not specified, this attribute is set to the value of the maxHttpHeaderSize attribute. + If you see "Request header is too large" errors you can increase this, + but be aware that Tomcat will allocate the full amount you specify for + every request. For example, if you specify a maxHttpRequestHeaderSize of + 1 MB and your application handles 100 concurrent requests, you will see + 100 MB of heap consumed by request headers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [DISCUSS] EOL date for 8.5.x
Mark, On 10/20/22 04:44, Mark Thomas wrote: Bump. On 07/10/2022 10:27, Mark Thomas wrote: Hi all, I don't think there is a need to make a decision on this quickly, but based on past experience and the current discussions about Jakarta EE 11 I think this is something we need to start thinking about. Some key facts: - Tomcat 7.0.x reached EOL on 31 March 2021 - EOL dates for major versions tend to be 3-4 years apart - We aim to support 3 major versions in parallel - currently 8.5.x, 9.0.x and 10.1.x. - Tomcat 11 will implement Jakarta EE 11 - Current Jakarta EE discussions are around a release in ~1 year - Ideally, Tomcat 8.5.x EOL would be just after Tomcat 11 is declared stable Based on the above I think EOL for 8.5.x should be either 31 March 2024 or 30 Sept 2024 depending on when we think Jakarta EE 11 will be released. Jakarta EE releases have tendency to slip so I think the 30 Sept 2024 is probably the more likely. However, it is much easier to delay an EOL date than to bring to bring it forward so my current thinking is to announce 31 March 2024 as the EOL date for 8.5.x and keep in mind that we can extend that if we want to. That seems reasonable. Were you thinking that we should announce that approximate date /now/ or wait until March 2023 and give 12 months notice? If we are agreed, I don't see a particular reason to wait. I'm wondering if I should migrate my applications to 9.0 or 10.x and start re-writing imports. The flexibility of Tomcat 10.x is just incredible. I'm kind of leaning toward skipping 9.x. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch loom created (now 6a22f2f399)
Mark, On 10/20/22 05:28, Mark Thomas wrote: On 20/10/2022 09:32, Rémy Maucherat wrote: This is interesting since now is the best time to discuss long term plans. We'll see if there are some scheduling gains with Loom ... But I don't think thread scheduling was the problem in Tomcat. Maybe lock concurrency but it seems these had been eliminated (or improved at least). I still don't understand how it could possibly really work though, right now it feels like asking if Windows 3 cooperative multitasking could work (= it works as long as all apps and libraries are perfectly coded and there's no bug whatsoever). Also having to avoid native code is annoying (just when there's finally something good like Panama ...). I went through the Jakarta Servlet mailing list and there are some discussions about Loom and a possible lower level API. It seems there's a discussion between blocking and non blocking APIs. Well, IMO we need both ... - Blocking: For Loom. And mostly it could simply be ServletRequest/Response/Cookie/IS/OS without any of the other items. So it looks like everything is in there already. - Async: Great if Loom isn't that appropriate for real work. However, the listeners used for the Servlet API are not a very nice async API (of course they are very appropriate as an extension for a blocking API). So maybe that's where the new work is: come up with an async API ? What do you think ? There are a lot of dimensions to this problem space. I have an initial implementation of the Loom module that supports the blocking parts of the Servlet API. I am currently working on the necessary refactoring to optimise that for Loom. I hope to get that committed later this week or early next. My working assumption is that any benefits Loom can provide will be in the blocking API. I don't see any way Loom could support the async and non-blocking APIs without adding some overhead - even if that overhead is negligible. Therefore, rather than moving on to try and implement support for the async and non-blocking parts of the Servlet API with the Loom connector, I'd like to spend some time exploring the performance of Loom with the blocking API. Hopefully, others here will also be able to undertake their own performance tests. I have only tested a couple of scenarios that aren't particularly suited to Loom (requests to a simple servlet) and the results are increased CPU usage and reduced throughput with Loom compared to NIO. I want to look at some tests that are more tailored to demonstrate the benefits of Loom. My expectation is that we will identify some scenarios where switching to the Loom module provides immediate benefits with no application changes. What will be interesting is how that compares to refactoring the application to use async and/or non-blocking. The other question is the extent to which the refactoring I have completed so far is necessary. I am not seeing much benefit from the optimisations I am implementing. It may be that a much simpler approach of integrating Loom (essentially a custom executor) is good enough. Note that this may mean undoing some of the refactoring I am currently implementing in Tomcat 11. Once we have that data, then I think we'll be in a position to decide the extent to which it makes sense to support Loom and whether or not to proceed and implement support for async and non-blocking in the Loom module. There is clearly a demand for a lower-level HTTP API. The question for me at this point is whether that should be async based or blocking (Loom) based. Based on what I have seen so far, I think Greg Wilkins has called it correctly and that async will have the edge. However, that is more judgement/instinct than based on hard data. I want to see more data before making forming a final view. Comet FTW? -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch loom created (now 6a22f2f399)
Rémy, On 10/21/22 05:27, Rémy Maucherat wrote: On Thu, Oct 20, 2022 at 3:46 PM Rémy Maucherat wrote: Ok, that is reasonable and seeing what can be expected in the best case is a good plan. Async will indeed be a bit more expensive with Loom, just like blocking is more expensive with NIO(2). I'm starting testing, and it looks like the basics work, as you said. The first item is to identify a best case scenario for Loom. I decided to try with a static file (in the context of Tomcat, a low level API would be very similar in terms of IO), but maybe this is not it and a Servlet doing computations would be better for Loom (with less IO load). Pulling out my good old ab, I have some rather interesting results. -c 1 (no concurrency) is looking awesome for Loom, where it basically destroys NIO. However, it degrades quickly from there. -c 2 is already a lot closer. -c 5 is the inflexion point where NIO pulls ahead. Then as concurrency increases Loom becomes slower. Thankfully, it doesn't degrade too much from there and with high concurrency it remains reasonably close. I don't have a high core count CPU though so this could make for some differences as well. Overall I would say this matches your finding. I tested with my panama-foreign Java "20" build. We should probably wait for the real Java 20 to start making decisions. If the performance of Loom is currently essentially on-par with NIO, my expectation is that, over time, it will increase quite a bit. I'm sure there is tons of code in the Loom implementation that can be optimized, removed, etc. whereas NIO has had a decade of similar optimizations already. But if we have to have 25% more code to get 5-10% performance improvement, I'm not sure it's worth it. (I'm sure our colleagues at AWS will disagree!) -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
