Drop module-info from tomcat*.jar?

[Romain Manni-Bucau]

Hi all,

I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.
The issues I hit:

- Tomcat is designed to be fully used with JPMS whereas I would like to be
able to use it in the CP if a jlink custom distro (without forking/patching
tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina for
ex)

Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:

1. dropping it
2. making it optional (I assume it can be released in jars with classifiers
only)
3. making it more accurate - but this highly depends how the user consumes
it (in particular for tomcat embed flavor)

Personally I tend to priviledge 1 cause 3 makes it hard to do right but
happy with other solutions not requiring to fork.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Re: Drop module-info from tomcat*.jar?

[Mark Thomas]

On 15/09/2021 08:34, Romain Manni-Bucau wrote:

Hi all,

I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.


I am assuming this is with embedded.


The issues I hit:

- Tomcat is designed to be fully used with JPMS whereas I would like to be
able to use it in the CP if a jlink custom distro (without forking/patching
tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina for
ex)

Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:

1. dropping it


Not an option as we have users that have requested it.


2. making it optional (I assume it can be released in jars with classifiers
only)


Maybe, but it adds a bunch of artefacts.


3. making it more accurate - but this highly depends how the user consumes
it (in particular for tomcat embed flavor)


I think a variation of this is the way to go.

Looking at the list of dependencies, I suspect most of them can be made 
optional. That involves fine-tuning the bnd configuration files.


That does raise the question what we do when a user tries to use the 
optional features. I think we need to:

- identify those Tomcat features that depend on optional modules
- add a check for the presence of the module before using the feature
  and log an appropriate error message if the module is missing.

Splitting embedded into lots of little modules where all the 
dependencies are correctly declared is another solution but we have 
users that have requested we provide Tomcat in as few JARs as possible.


I think we are approaching "can't please all of the people, all of the 
time" territory here.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] cklein05 commented on pull request #428: Enhancement: Additional user attributes queried by (some) realms

[GitBox]

cklein05 commented on pull request #428:
URL: https://github.com/apache/tomcat/pull/428#issuecomment-919880264


   That's it for now. Is anyone willing to merge and port back? :)


-- 
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

Re: Drop module-info from tomcat*.jar?

[Romain Manni-Bucau]

I think the last option is maybe the target: modularize tomcat properly.
The people willing to have as few as possible modules would just use a new
"bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
which provides a bundle way of building apps but is not flexible.
So regarding JPMS I think it is either being really modular or not being
modular since the in between state leads to unsatisfied people and the
biggest constraints come from JPMS.
Is it something targettable or do you think it is too much work?

side note: fine for me if it targets only 10.1.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 15 sept. 2021 à 11:17, Mark Thomas  a écrit :

> On 15/09/2021 08:34, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > I was trying to strim down a JDK, all was smooth until I started to work
> > with Tomcat.
>
> I am assuming this is with embedded.
>
> > The issues I hit:
> >
> > - Tomcat is designed to be fully used with JPMS whereas I would like to
> be
> > able to use it in the CP if a jlink custom distro (without
> forking/patching
> > tomcat jar indeed)
> > - module-info use "requires" and no optional dependent modules which lead
> > to way too much dependencies (open the module-info from tomcat-catalina
> for
> > ex)
> >
> > Indeed there are always workaround and way to achieve what I wanted but I
> > think the JPMS deliveries of Tomat are not friendly so think it is worth
> > thinking about:
> >
> > 1. dropping it
>
> Not an option as we have users that have requested it.
>
> > 2. making it optional (I assume it can be released in jars with
> classifiers
> > only)
>
> Maybe, but it adds a bunch of artefacts.
>
> > 3. making it more accurate - but this highly depends how the user
> consumes
> > it (in particular for tomcat embed flavor)
>
> I think a variation of this is the way to go.
>
> Looking at the list of dependencies, I suspect most of them can be made
> optional. That involves fine-tuning the bnd configuration files.
>
> That does raise the question what we do when a user tries to use the
> optional features. I think we need to:
> - identify those Tomcat features that depend on optional modules
> - add a check for the presence of the module before using the feature
>and log an appropriate error message if the module is missing.
>
> Splitting embedded into lots of little modules where all the
> dependencies are correctly declared is another solution but we have
> users that have requested we provide Tomcat in as few JARs as possible.
>
> I think we are approaching "can't please all of the people, all of the
> time" territory here.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[Bug 65517] upgrade to axis2-adb 1.8.0 to address CVE-2020-0822

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65517

--- Comment #1 from Mikko Suonio  ---
Can you comment on why this is invalid? Since this is related to a CVE, the
impact needs to be analyzed in many organizations.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Release Announcement: General Availability of Java 17 / JDK 17

[Martin Grigorov]

Hi Rory,

Congratiolations for JDK 17 GA!

Apache Tomcat 10.1.x build and tests pass successfully with
JDK 18-ea+14-756 on both Linux x86_64 and aarch64 !

Regards,
Martin

On Tue, Sep 14, 2021 at 6:55 PM Rory O'Donnell 
wrote:

> Hi Mark,
>
> *Release Announcement: General Availability of Java 17 / JDK 17 *
>
> **
>
>   * JDK 17, the reference implementation of Java 17, is now Generally
> Available. [1]
>   * GPL-licensed OpenJDK builds from Oracle are available here:
> https://jdk.java.net/17/ 
>   * JDK 17 Release notes
> 
>   * Inside Java: The Arrival of Java 17!
> 
>
> *JDK 17 includes the following features [2]:*
>
>   * JEP 306: Restore Always-Strict Floating-Point Semantics
> 
>   * JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   * JEP 382: New macOS Rendering Pipeline
> 
>   * JEP 391: macOS/AArch64 Port 
>   * JEP 398: Deprecate the Applet API for Removal
> 
>   * JEP 403: Strongly Encapsulate JDK Internals
> 
>   * JEP 406: Pattern Matching for switch (Preview)
> 
>   * JEP 407: Remove RMI Activation 
>   * JEP 409: Sealed Classes 
>   * JEP 410: Remove the Experimental AOT and JIT Compiler
> 
>   * JEP 411: Deprecate the Security Manager for Removal
> 
>   * JEP 412: Foreign Function & Memory API (Incubator)
> 
>   * JEP 414: Vector API (Second Incubator)
> 
>   * JEP 415: Context-Specific Deserialization Filters
> 
>
> *JDK 17 will be a long-term-support (LTS) release* from most
> vendors,including Oracle. If you’re upgrading from the previous LTS
> release,JDK 11, then you have many more JEPs to look forward to,
> summarized here:
>
> https://openjdk.java.net/jdk/17/jeps-since-jdk-11
> 
>
>
> Thanks to everyone who contributed to JDK 17, whether by creating
> features or enhancements, logging bugs, or
>
> downloading and testing the early-access builds.
>
>
> *OpenJDK 18 Early Access build 14 is now available at
> https://jdk.java.net/18/ 
> *
>
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * JEPs targeted to JDK 18, so far:
>   o JEP 400: UTF-8 by Default 
>   o JEP 413: Code Snippets in Java API Documentation
> 
>
>   * Release Notes are available at https://jdk.java.net/18/release-notes
> 
>
>   * Significant changes since the last availability email:
>   o JDK-8271745: Fix Issues With the KW and KWP Modes of SunJCE
> Provider
>   o JDK-8262186: Call X509KeyManager.chooseClientAlias once for all
> key types
>   o JDK-8225083: Remove Google certificate that is expiring in
> December 2021
>   o JDK-8251329: Zip File System Provider Throws ZipException when
> entry name element contains "." or ".."
>   o JDK-8225082: Remove IdenTrust certificate that is expiring in
> September 2021
>   o
>
> *Project Loom Early-Access Builds*
>
>   * Build 18-loom+2-74 (2021/8/7) based on jdk-18+9
>  is
> available - https://jdk.java.net/loom/ 
>   * These early access, open source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> Rgds,Rory
>
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/006037.html
>
> [2] https://openjdk.java.net/projects/jdk/17/
> 
>
>

[Bug 65517] upgrade to axis2-adb 1.8.0 to address CVE-2020-0822

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65517

--- Comment #2 from Mark Thomas  ---
Let me turn that around. What is your basis for claiming that this is a valid
vulnerability in Apache Tomcat?

(Hint: The original description for this contained multiple inaccuracies so
don't take any of that information at face value)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Drop module-info from tomcat*.jar?

[Mark Thomas]

On 15/09/2021 11:07, Romain Manni-Bucau wrote:

I think the last option is maybe the target: modularize tomcat properly.


"Properly" is a highly subjective judgement. There are going to be 
wildly differing views on what constitutes a "proper" degree of modularity.



The people willing to have as few as possible modules would just use a new
"bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
which provides a bundle way of building apps but is not flexible.
So regarding JPMS I think it is either being really modular or not being
modular since the in between state leads to unsatisfied people and the
biggest constraints come from JPMS.
Is it something targettable or do you think it is too much work?


Don't know until we try.

My instinct is that making more modules optional and then logging 
warnings if users try to use Tomcat features that depend on a missing 
optional module is doable - but I haven't done any analysis to back that up.


I don't have a sense of how many more modules like SSI could be 
realistically created.


Broadly, embedded is going to be the "bundle" module (well, modules) and 
if folks want a finer-grained selection then they can use the JARs from 
the standard distribution.


Mark




side note: fine for me if it targets only 10.1.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 15 sept. 2021 à 11:17, Mark Thomas  a écrit :


On 15/09/2021 08:34, Romain Manni-Bucau wrote:

Hi all,

I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.


I am assuming this is with embedded.


The issues I hit:

- Tomcat is designed to be fully used with JPMS whereas I would like to

be

able to use it in the CP if a jlink custom distro (without

forking/patching

tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina

for

ex)

Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:

1. dropping it


Not an option as we have users that have requested it.


2. making it optional (I assume it can be released in jars with

classifiers

only)


Maybe, but it adds a bunch of artefacts.


3. making it more accurate - but this highly depends how the user

consumes

it (in particular for tomcat embed flavor)


I think a variation of this is the way to go.

Looking at the list of dependencies, I suspect most of them can be made
optional. That involves fine-tuning the bnd configuration files.

That does raise the question what we do when a user tries to use the
optional features. I think we need to:
- identify those Tomcat features that depend on optional modules
- add a check for the presence of the module before using the feature
and log an appropriate error message if the module is missing.

Splitting embedded into lots of little modules where all the
dependencies are correctly declared is another solution but we have
users that have requested we provide Tomcat in as few JARs as possible.

I think we are approaching "can't please all of the people, all of the
time" territory here.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Drop module-info from tomcat*.jar?

[Romain Manni-Bucau]

Le mer. 15 sept. 2021 à 13:13, Mark Thomas  a écrit :

> On 15/09/2021 11:07, Romain Manni-Bucau wrote:
> > I think the last option is maybe the target: modularize tomcat properly.
>
> "Properly" is a highly subjective judgement. There are going to be
> wildly differing views on what constitutes a "proper" degree of modularity.
>

Ok, "properly" regarding the dependency graph, ie no reflection done nor
code relying on an optional dependency (all that replaced by a SPI or
alike).


>
> > The people willing to have as few as possible modules would just use a
> new
> > "bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
> > which provides a bundle way of building apps but is not flexible.
> > So regarding JPMS I think it is either being really modular or not being
> > modular since the in between state leads to unsatisfied people and the
> > biggest constraints come from JPMS.
> > Is it something targettable or do you think it is too much work?
>
> Don't know until we try.
>
> My instinct is that making more modules optional and then logging
> warnings if users try to use Tomcat features that depend on a missing
> optional module is doable - but I haven't done any analysis to back that
> up.
>
> I don't have a sense of how many more modules like SSI could be
> realistically created.
>
> Broadly, embedded is going to be the "bundle" module (well, modules) and
> if folks want a finer-grained selection then they can use the JARs from
> the standard distribution.
>

To be honest I never understood why the org.apache.tomcat.embed artifacts,
they are generally the same as org.apache.tomcat ones and embedded server
works very well with org.apache.tomcat artifacts so can be good to drop
embed groupId and replace it by an all in one? Still thinking out loud
indeed but current modularisation is surprising for consumers ;).


>
> Mark
>
>
> >
> > side note: fine for me if it targets only 10.1.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 15 sept. 2021 à 11:17, Mark Thomas  a écrit :
> >
> >> On 15/09/2021 08:34, Romain Manni-Bucau wrote:
> >>> Hi all,
> >>>
> >>> I was trying to strim down a JDK, all was smooth until I started to
> work
> >>> with Tomcat.
> >>
> >> I am assuming this is with embedded.
> >>
> >>> The issues I hit:
> >>>
> >>> - Tomcat is designed to be fully used with JPMS whereas I would like to
> >> be
> >>> able to use it in the CP if a jlink custom distro (without
> >> forking/patching
> >>> tomcat jar indeed)
> >>> - module-info use "requires" and no optional dependent modules which
> lead
> >>> to way too much dependencies (open the module-info from tomcat-catalina
> >> for
> >>> ex)
> >>>
> >>> Indeed there are always workaround and way to achieve what I wanted
> but I
> >>> think the JPMS deliveries of Tomat are not friendly so think it is
> worth
> >>> thinking about:
> >>>
> >>> 1. dropping it
> >>
> >> Not an option as we have users that have requested it.
> >>
> >>> 2. making it optional (I assume it can be released in jars with
> >> classifiers
> >>> only)
> >>
> >> Maybe, but it adds a bunch of artefacts.
> >>
> >>> 3. making it more accurate - but this highly depends how the user
> >> consumes
> >>> it (in particular for tomcat embed flavor)
> >>
> >> I think a variation of this is the way to go.
> >>
> >> Looking at the list of dependencies, I suspect most of them can be made
> >> optional. That involves fine-tuning the bnd configuration files.
> >>
> >> That does raise the question what we do when a user tries to use the
> >> optional features. I think we need to:
> >> - identify those Tomcat features that depend on optional modules
> >> - add a check for the presence of the module before using the feature
> >> and log an appropriate error message if the module is missing.
> >>
> >> Splitting embedded into lots of little modules where all the
> >> dependencies are correctly declared is another solution but we have
> >> users that have requested we provide Tomcat in as few JARs as possible.
> >>
> >> I think we are approaching "can't please all of the people, all of the
> >> time" territory here.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.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 (1988fad -> dee5f2c)

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from 1988fad  Merge pull request #450 from tussupbekov/typo-fix
 new 60baeb2  Fix a potential cause of intermittent test failure
 new 7a1441a  Move debug statement inside sync block
 new 0a86874  Make synchronized as method assumes a lock is held on the 
instance
 new dee5f2c  Refactor allocations for the connection flow control window

The 4 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 318 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |  12 +-
 .../apache/coyote/http2/TestHttp2Section_5_3.java  |   5 +
 webapps/docs/changelog.xml |   6 +
 6 files changed, 165 insertions(+), 207 deletions(-)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 01/04: Fix a potential cause of intermittent test failure

[markt]

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

commit 60baeb2128d72416f13753ce7091b15a537343fa
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:47:35 2021 +0100

Fix a potential cause of intermittent test failure
---
 test/org/apache/coyote/http2/TestHttp2Section_5_3.java | 5 +
 1 file changed, 5 insertions(+)

diff --git a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java 
b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
index d85c620..6001b3e 100644
--- a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
+++ b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
@@ -177,6 +177,11 @@ public class TestHttp2Section_5_3 extends Http2TestBase {
 output.clearTrace();
 }
 
+// Need to give both server side threads enough time to request an
+// allocation from the connection flow control window before sending
+// the next window update.
+Thread.sleep(1000);
+
 sendWindowUpdate(0, 1024);
 parser.readFrame(true);
 

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 03/04: Make synchronized as method assumes a lock is held on the instance

[markt]

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

commit 0a86874349c08b01a96f3c1f9f1f51dddbb74528
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:56:45 2021 +0100

Make synchronized as method assumes a lock is held on the instance
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index f28ae6d..045337a 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -1056,7 +1056,7 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 }
 
 
-private int allocate(AbstractStream stream, int allocation) {
+private synchronized int allocate(AbstractStream stream, int allocation) {
 if (log.isDebugEnabled()) {
 log.debug(sm.getString("upgradeHandler.allocate.debug", 
getConnectionId(),
 stream.getIdAsString(), Integer.toString(allocation)));

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 02/04: Move debug statement inside sync block

[markt]

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

commit 7a1441acb6a2c527d97d345e99309e36e1e72a39
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:52:42 2021 +0100

Move debug statement inside sync block

Ensures that the values logged are consistent with the values processed.
---
 java/org/apache/coyote/http2/WindowAllocationManager.java | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/coyote/http2/WindowAllocationManager.java 
b/java/org/apache/coyote/http2/WindowAllocationManager.java
index 96016cc..6c824a5 100644
--- a/java/org/apache/coyote/http2/WindowAllocationManager.java
+++ b/java/org/apache/coyote/http2/WindowAllocationManager.java
@@ -172,12 +172,13 @@ class WindowAllocationManager {
 
 
 private void notify(int notifyTarget) {
-if (log.isDebugEnabled()) {
-log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
-stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
-}
 
 synchronized (stream) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
+stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
+}
+
 if ((notifyTarget & waitingFor) > NONE) {
 // Reset this here so multiple notifies (possible with a
 // backlog containing multiple streams and small window 
updates)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 04/04: Refactor allocations for the connection flow control window

[markt]

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

commit dee5f2c1f744e789ab3a422de79385222d07ba6e
Author: Mark Thomas 
AuthorDate: Wed Sep 15 14:12:26 2021 +0100

Refactor allocations for the connection flow control window

There are multiple related changes in this commit
- The BackLog tracker object is removed and replaced with fields on
  AbstractStream.
- If an incomplete allocation is made for a stream as a result of a
  WINDOW_UPDATE frame the remainder of the request is now discarded
- The connection flow control window is, effectively, reduced as soon as
  an allocation is made rather than waiting until after the Stream is
  released. This is an improvement over the previous approach where over
  allocation was possible.
- The loop in reserveWindowSize is removed
---
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 316 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |   3 +-
 webapps/docs/changelog.xml |   6 +
 5 files changed, 154 insertions(+), 202 deletions(-)

diff --git a/java/org/apache/coyote/http2/AbstractStream.java 
b/java/org/apache/coyote/http2/AbstractStream.java
index c7374b6..6a825c2 100644
--- a/java/org/apache/coyote/http2/AbstractStream.java
+++ b/java/org/apache/coyote/http2/AbstractStream.java
@@ -40,6 +40,9 @@ abstract class AbstractStream {
 private final Set childStreams = 
Collections.newSetFromMap(new ConcurrentHashMap<>());
 private long windowSize = 
ConnectionSettingsBase.DEFAULT_INITIAL_WINDOW_SIZE;
 
+private volatile int connectionAllocationRequested = 0;
+private volatile int connectionAllocationMade = 0;
+
 
 AbstractStream(Integer identifier) {
 this.identifier = identifier;
@@ -154,6 +157,30 @@ abstract class AbstractStream {
 }
 
 
+final int getConnectionAllocationRequested() {
+return connectionAllocationRequested;
+}
+
+
+final void setConnectionAllocationRequested(int 
connectionAllocationRequested) {
+
log.debug(sm.getString("abstractStream.setConnectionAllocationRequested", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationRequested), 
Integer.toString(connectionAllocationRequested)));
+this.connectionAllocationRequested = connectionAllocationRequested;
+}
+
+
+final int getConnectionAllocationMade() {
+return connectionAllocationMade;
+}
+
+
+final void setConnectionAllocationMade(int connectionAllocationMade) {
+log.debug(sm.getString("abstractStream.setConnectionAllocationMade", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationMade), 
Integer.toString(connectionAllocationMade)));
+this.connectionAllocationMade = connectionAllocationMade;
+}
+
+
 abstract String getConnectionId();
 
 abstract int getWeight();
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 045337a..529b4f7 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -20,10 +20,9 @@ import java.io.EOFException;
 import java.io.IOException;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
+import java.util.Collections;
 import java.util.HashSet;
 import java.util.Iterator;
-import java.util.Map;
-import java.util.Map.Entry;
 import java.util.Queue;
 import java.util.Set;
 import java.util.TreeSet;
@@ -132,7 +131,7 @@ class Http2UpgradeHandler extends AbstractStream implements 
InternalHttpUpgradeH
 private final AtomicInteger nextLocalStreamId = new AtomicInteger(2);
 private final PingManager pingManager = getPingManager();
 private volatile int newStreamsSinceLastPrune = 0;
-private final Map backLogStreams = new 
ConcurrentHashMap<>();
+private final Set backLogStreams = 
Collections.newSetFromMap(new ConcurrentHashMap<>());
 private long backLogSize = 0;
 // The time at which the connection will timeout unless data arrives before
 // then. -1 means no timeout.
@@ -873,101 +872,81 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // this thread until after this thread enters wait()
 int allocation = 0;
 synchronized (stream) {
-do {
-synchronized (this) {
-if (!stream.canWrite()) {
-
stream.doStreamCancel(sm.getString("upgradeHandler.stream.notWritable",
-stream.getConnectionId(), 
stream.getIdAsString()), Http2Error.STREAM_CLOSED);
-}
-lon

[tomcat] branch 10.0.x updated (da5ce59 -> 23be856)

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from da5ce59  Fix typo
 new 1e34825  Avoid StackOverflowException
 new 0d409fb  Fix a potential cause of intermittent test failure
 new f61a413  Move debug statement inside sync block
 new 2653750  Make synchronized as method assumes a lock is held on the 
instance
 new 23be856  Refactor allocations for the connection flow control window

The 5 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../coyote/http2/Http2AsyncUpgradeHandler.java | 127 
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 318 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |  12 +-
 .../apache/coyote/http2/TestHttp2Section_5_3.java  |   5 +
 webapps/docs/changelog.xml |  10 +
 7 files changed, 240 insertions(+), 263 deletions(-)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 01/05: Avoid StackOverflowException

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 1e34825322e5d9ebadc9e8f128fb44ce76e4b3f9
Author: Mark Thomas 
AuthorDate: Fri Sep 10 08:21:36 2021 +0100

Avoid StackOverflowException

On a fast network (e.g. localhost) the writes all complete in-line. That
leads to the CompletionHandler triggering another write, which triggers
the CompletionHandler which trigegrs another write and so on. With large
response bodies and recursive in-line writes, it is easy to trigger a
StackOverflowException.
---
 .../coyote/http2/Http2AsyncUpgradeHandler.java | 127 -
 webapps/docs/changelog.xml |   4 +
 2 files changed, 75 insertions(+), 56 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index 5d11879..0b67c4c 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -36,6 +36,7 @@ import org.apache.tomcat.util.http.MimeHeaders;
 import org.apache.tomcat.util.net.SendfileState;
 import org.apache.tomcat.util.net.SocketWrapperBase;
 import org.apache.tomcat.util.net.SocketWrapperBase.BlockingMode;
+import org.apache.tomcat.util.net.SocketWrapperBase.CompletionState;
 
 public class Http2AsyncUpgradeHandler extends Http2UpgradeHandler {
 
@@ -363,70 +364,84 @@ public class Http2AsyncUpgradeHandler extends 
Http2UpgradeHandler {
 protected class SendfileCompletionHandler implements 
CompletionHandler {
 @Override
 public void completed(Long nBytes, SendfileData sendfile) {
+CompletionState completionState = null;
 long bytesWritten = nBytes.longValue() - 9;
-sendfile.left -= bytesWritten;
-if (sendfile.left == 0) {
-try {
-sendfile.stream.getOutputBuffer().end();
-} catch (IOException e) {
-failed(e, sendfile);
+
+/*
+ * Loop for in-line writes only. Avoids a possible stack-overflow 
of
+ * chained completion handlers with a long series of in-line 
writes.
+ */
+do {
+sendfile.left -= bytesWritten;
+if (sendfile.left == 0) {
+try {
+sendfile.stream.getOutputBuffer().end();
+} catch (IOException e) {
+failed(e, sendfile);
+}
+return;
 }
-return;
-}
-sendfile.streamReservation -= bytesWritten;
-sendfile.connectionReservation -= bytesWritten;
-sendfile.pos += bytesWritten;
-try {
-if (sendfile.connectionReservation == 0) {
-if (sendfile.streamReservation == 0) {
-int reservation = (sendfile.end - sendfile.pos > 
Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int) (sendfile.end - sendfile.pos);
-sendfile.streamReservation = 
sendfile.stream.reserveWindowSize(reservation, true);
+sendfile.streamReservation -= bytesWritten;
+sendfile.connectionReservation -= bytesWritten;
+sendfile.pos += bytesWritten;
+try {
+if (sendfile.connectionReservation == 0) {
+if (sendfile.streamReservation == 0) {
+int reservation = (sendfile.end - sendfile.pos > 
Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int) (sendfile.end - sendfile.pos);
+sendfile.streamReservation = 
sendfile.stream.reserveWindowSize(reservation, true);
+}
+sendfile.connectionReservation = 
reserveWindowSize(sendfile.stream, sendfile.streamReservation, true);
 }
-sendfile.connectionReservation = 
reserveWindowSize(sendfile.stream, sendfile.streamReservation, true);
+} catch (IOException e) {
+failed (e, sendfile);
+return;
 }
-} catch (IOException e) {
-failed (e, sendfile);
-return;
-}
 
-if (log.isDebugEnabled()) {
-log.debug(sm.getString("upgradeHandler.sendfile.reservation", 
connectionId, sendfile.stream.getIdAsString(),
-Integer.valueOf(sendfile.connectionReservation), 
Integer.valueOf(sendfile.streamReservation)));
-}
-
-// connectionReservation will always be smaller than or the same as
-// streamReservation
-int frameSize = Integer.min(getMaxFrameSize(), 
sendfile.connectionReservation);
-bool

[tomcat] 02/05: Fix a potential cause of intermittent test failure

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 0d409fbeb62a594f681893f9a5585abcb6259656
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:47:35 2021 +0100

Fix a potential cause of intermittent test failure
---
 test/org/apache/coyote/http2/TestHttp2Section_5_3.java | 5 +
 1 file changed, 5 insertions(+)

diff --git a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java 
b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
index d85c620..6001b3e 100644
--- a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
+++ b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
@@ -177,6 +177,11 @@ public class TestHttp2Section_5_3 extends Http2TestBase {
 output.clearTrace();
 }
 
+// Need to give both server side threads enough time to request an
+// allocation from the connection flow control window before sending
+// the next window update.
+Thread.sleep(1000);
+
 sendWindowUpdate(0, 1024);
 parser.readFrame(true);
 

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 05/05: Refactor allocations for the connection flow control window

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 23be85654d4121718610aea7a586af5748a310c9
Author: Mark Thomas 
AuthorDate: Wed Sep 15 14:12:26 2021 +0100

Refactor allocations for the connection flow control window

There are multiple related changes in this commit
- The BackLog tracker object is removed and replaced with fields on
  AbstractStream.
- If an incomplete allocation is made for a stream as a result of a
  WINDOW_UPDATE frame the remainder of the request is now discarded
- The connection flow control window is, effectively, reduced as soon as
  an allocation is made rather than waiting until after the Stream is
  released. This is an improvement over the previous approach where over
  allocation was possible.
- The loop in reserveWindowSize is removed
---
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 316 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |   3 +-
 webapps/docs/changelog.xml |   6 +
 5 files changed, 154 insertions(+), 202 deletions(-)

diff --git a/java/org/apache/coyote/http2/AbstractStream.java 
b/java/org/apache/coyote/http2/AbstractStream.java
index c7374b6..6a825c2 100644
--- a/java/org/apache/coyote/http2/AbstractStream.java
+++ b/java/org/apache/coyote/http2/AbstractStream.java
@@ -40,6 +40,9 @@ abstract class AbstractStream {
 private final Set childStreams = 
Collections.newSetFromMap(new ConcurrentHashMap<>());
 private long windowSize = 
ConnectionSettingsBase.DEFAULT_INITIAL_WINDOW_SIZE;
 
+private volatile int connectionAllocationRequested = 0;
+private volatile int connectionAllocationMade = 0;
+
 
 AbstractStream(Integer identifier) {
 this.identifier = identifier;
@@ -154,6 +157,30 @@ abstract class AbstractStream {
 }
 
 
+final int getConnectionAllocationRequested() {
+return connectionAllocationRequested;
+}
+
+
+final void setConnectionAllocationRequested(int 
connectionAllocationRequested) {
+
log.debug(sm.getString("abstractStream.setConnectionAllocationRequested", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationRequested), 
Integer.toString(connectionAllocationRequested)));
+this.connectionAllocationRequested = connectionAllocationRequested;
+}
+
+
+final int getConnectionAllocationMade() {
+return connectionAllocationMade;
+}
+
+
+final void setConnectionAllocationMade(int connectionAllocationMade) {
+log.debug(sm.getString("abstractStream.setConnectionAllocationMade", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationMade), 
Integer.toString(connectionAllocationMade)));
+this.connectionAllocationMade = connectionAllocationMade;
+}
+
+
 abstract String getConnectionId();
 
 abstract int getWeight();
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 045337a..529b4f7 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -20,10 +20,9 @@ import java.io.EOFException;
 import java.io.IOException;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
+import java.util.Collections;
 import java.util.HashSet;
 import java.util.Iterator;
-import java.util.Map;
-import java.util.Map.Entry;
 import java.util.Queue;
 import java.util.Set;
 import java.util.TreeSet;
@@ -132,7 +131,7 @@ class Http2UpgradeHandler extends AbstractStream implements 
InternalHttpUpgradeH
 private final AtomicInteger nextLocalStreamId = new AtomicInteger(2);
 private final PingManager pingManager = getPingManager();
 private volatile int newStreamsSinceLastPrune = 0;
-private final Map backLogStreams = new 
ConcurrentHashMap<>();
+private final Set backLogStreams = 
Collections.newSetFromMap(new ConcurrentHashMap<>());
 private long backLogSize = 0;
 // The time at which the connection will timeout unless data arrives before
 // then. -1 means no timeout.
@@ -873,101 +872,81 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // this thread until after this thread enters wait()
 int allocation = 0;
 synchronized (stream) {
-do {
-synchronized (this) {
-if (!stream.canWrite()) {
-
stream.doStreamCancel(sm.getString("upgradeHandler.stream.notWritable",
-stream.getConnectionId(), 
stream.getIdAsString()), Http2Error.STREAM_CLOSED);
-}
-l

[tomcat] 04/05: Make synchronized as method assumes a lock is held on the instance

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 2653750ce02b94de559dd0396c8a42055ef7dd4c
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:56:45 2021 +0100

Make synchronized as method assumes a lock is held on the instance
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index f28ae6d..045337a 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -1056,7 +1056,7 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 }
 
 
-private int allocate(AbstractStream stream, int allocation) {
+private synchronized int allocate(AbstractStream stream, int allocation) {
 if (log.isDebugEnabled()) {
 log.debug(sm.getString("upgradeHandler.allocate.debug", 
getConnectionId(),
 stream.getIdAsString(), Integer.toString(allocation)));

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 03/05: Move debug statement inside sync block

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit f61a413f176928e50c73831eaa433d71a403119a
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:52:42 2021 +0100

Move debug statement inside sync block

Ensures that the values logged are consistent with the values processed.
---
 java/org/apache/coyote/http2/WindowAllocationManager.java | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/coyote/http2/WindowAllocationManager.java 
b/java/org/apache/coyote/http2/WindowAllocationManager.java
index 96016cc..6c824a5 100644
--- a/java/org/apache/coyote/http2/WindowAllocationManager.java
+++ b/java/org/apache/coyote/http2/WindowAllocationManager.java
@@ -172,12 +172,13 @@ class WindowAllocationManager {
 
 
 private void notify(int notifyTarget) {
-if (log.isDebugEnabled()) {
-log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
-stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
-}
 
 synchronized (stream) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
+stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
+}
+
 if ((notifyTarget & waitingFor) > NONE) {
 // Reset this here so multiple notifies (possible with a
 // backlog containing multiple streams and small window 
updates)

-
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 (7bc0ebb -> c3f5655)

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from 7bc0ebb  Fix typo
 new 0b2a4f7  Avoid StackOverflowException
 new b97bd8b  Fix a potential cause of intermittent test failure
 new c846f70  Move debug statement inside sync block
 new ea400ae  Make synchronized as method assumes a lock is held on the 
instance
 new c3f5655  Refactor allocations for the connection flow control window

The 5 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../coyote/http2/Http2AsyncUpgradeHandler.java | 127 
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 318 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |  12 +-
 .../apache/coyote/http2/TestHttp2Section_5_3.java  |   5 +
 webapps/docs/changelog.xml |  10 +
 7 files changed, 240 insertions(+), 263 deletions(-)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 02/05: Fix a potential cause of intermittent test failure

[markt]

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

commit b97bd8bef6cc60d8f07abae867ec91d83dc0823f
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:47:35 2021 +0100

Fix a potential cause of intermittent test failure
---
 test/org/apache/coyote/http2/TestHttp2Section_5_3.java | 5 +
 1 file changed, 5 insertions(+)

diff --git a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java 
b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
index d85c620..6001b3e 100644
--- a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
+++ b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
@@ -177,6 +177,11 @@ public class TestHttp2Section_5_3 extends Http2TestBase {
 output.clearTrace();
 }
 
+// Need to give both server side threads enough time to request an
+// allocation from the connection flow control window before sending
+// the next window update.
+Thread.sleep(1000);
+
 sendWindowUpdate(0, 1024);
 parser.readFrame(true);
 

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 01/05: Avoid StackOverflowException

[markt]

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

commit 0b2a4f78e6347a2508c18008add025e820a40971
Author: Mark Thomas 
AuthorDate: Fri Sep 10 08:21:36 2021 +0100

Avoid StackOverflowException

On a fast network (e.g. localhost) the writes all complete in-line. That
leads to the CompletionHandler triggering another write, which triggers
the CompletionHandler which trigegrs another write and so on. With large
response bodies and recursive in-line writes, it is easy to trigger a
StackOverflowException.
---
 .../coyote/http2/Http2AsyncUpgradeHandler.java | 127 -
 webapps/docs/changelog.xml |   4 +
 2 files changed, 75 insertions(+), 56 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
index cc85313..5e0aa29 100644
--- a/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2AsyncUpgradeHandler.java
@@ -36,6 +36,7 @@ import org.apache.tomcat.util.http.MimeHeaders;
 import org.apache.tomcat.util.net.SendfileState;
 import org.apache.tomcat.util.net.SocketWrapperBase;
 import org.apache.tomcat.util.net.SocketWrapperBase.BlockingMode;
+import org.apache.tomcat.util.net.SocketWrapperBase.CompletionState;
 
 public class Http2AsyncUpgradeHandler extends Http2UpgradeHandler {
 
@@ -363,70 +364,84 @@ public class Http2AsyncUpgradeHandler extends 
Http2UpgradeHandler {
 protected class SendfileCompletionHandler implements 
CompletionHandler {
 @Override
 public void completed(Long nBytes, SendfileData sendfile) {
+CompletionState completionState = null;
 long bytesWritten = nBytes.longValue() - 9;
-sendfile.left -= bytesWritten;
-if (sendfile.left == 0) {
-try {
-sendfile.stream.getOutputBuffer().end();
-} catch (IOException e) {
-failed(e, sendfile);
+
+/*
+ * Loop for in-line writes only. Avoids a possible stack-overflow 
of
+ * chained completion handlers with a long series of in-line 
writes.
+ */
+do {
+sendfile.left -= bytesWritten;
+if (sendfile.left == 0) {
+try {
+sendfile.stream.getOutputBuffer().end();
+} catch (IOException e) {
+failed(e, sendfile);
+}
+return;
 }
-return;
-}
-sendfile.streamReservation -= bytesWritten;
-sendfile.connectionReservation -= bytesWritten;
-sendfile.pos += bytesWritten;
-try {
-if (sendfile.connectionReservation == 0) {
-if (sendfile.streamReservation == 0) {
-int reservation = (sendfile.end - sendfile.pos > 
Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int) (sendfile.end - sendfile.pos);
-sendfile.streamReservation = 
sendfile.stream.reserveWindowSize(reservation, true);
+sendfile.streamReservation -= bytesWritten;
+sendfile.connectionReservation -= bytesWritten;
+sendfile.pos += bytesWritten;
+try {
+if (sendfile.connectionReservation == 0) {
+if (sendfile.streamReservation == 0) {
+int reservation = (sendfile.end - sendfile.pos > 
Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int) (sendfile.end - sendfile.pos);
+sendfile.streamReservation = 
sendfile.stream.reserveWindowSize(reservation, true);
+}
+sendfile.connectionReservation = 
reserveWindowSize(sendfile.stream, sendfile.streamReservation, true);
 }
-sendfile.connectionReservation = 
reserveWindowSize(sendfile.stream, sendfile.streamReservation, true);
+} catch (IOException e) {
+failed (e, sendfile);
+return;
 }
-} catch (IOException e) {
-failed (e, sendfile);
-return;
-}
 
-if (log.isDebugEnabled()) {
-log.debug(sm.getString("upgradeHandler.sendfile.reservation", 
connectionId, sendfile.stream.getIdAsString(),
-Integer.valueOf(sendfile.connectionReservation), 
Integer.valueOf(sendfile.streamReservation)));
-}
-
-// connectionReservation will always be smaller than or the same as
-// streamReservation
-int frameSize = Integer.min(getMaxFrameSize(), 
sendfile.connectionReservation);
-boole

[tomcat] 03/05: Move debug statement inside sync block

[markt]

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

commit c846f70814a5b0f31d66acfdbff893641b8f9b8a
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:52:42 2021 +0100

Move debug statement inside sync block

Ensures that the values logged are consistent with the values processed.
---
 java/org/apache/coyote/http2/WindowAllocationManager.java | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/coyote/http2/WindowAllocationManager.java 
b/java/org/apache/coyote/http2/WindowAllocationManager.java
index 96016cc..6c824a5 100644
--- a/java/org/apache/coyote/http2/WindowAllocationManager.java
+++ b/java/org/apache/coyote/http2/WindowAllocationManager.java
@@ -172,12 +172,13 @@ class WindowAllocationManager {
 
 
 private void notify(int notifyTarget) {
-if (log.isDebugEnabled()) {
-log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
-stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
-}
 
 synchronized (stream) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
+stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
+}
+
 if ((notifyTarget & waitingFor) > NONE) {
 // Reset this here so multiple notifies (possible with a
 // backlog containing multiple streams and small window 
updates)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 04/05: Make synchronized as method assumes a lock is held on the instance

[markt]

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

commit ea400ae393037ff516505e639d626c511067f5e5
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:56:45 2021 +0100

Make synchronized as method assumes a lock is held on the instance
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 3b2a017..976f2ad 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -1056,7 +1056,7 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 }
 
 
-private int allocate(AbstractStream stream, int allocation) {
+private synchronized int allocate(AbstractStream stream, int allocation) {
 if (log.isDebugEnabled()) {
 log.debug(sm.getString("upgradeHandler.allocate.debug", 
getConnectionId(),
 stream.getIdAsString(), Integer.toString(allocation)));

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 05/05: Refactor allocations for the connection flow control window

[markt]

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

commit c3f5655929027cc791a3f4e1c52ffb7f29cf2b20
Author: Mark Thomas 
AuthorDate: Wed Sep 15 14:12:26 2021 +0100

Refactor allocations for the connection flow control window

There are multiple related changes in this commit
- The BackLog tracker object is removed and replaced with fields on
  AbstractStream.
- If an incomplete allocation is made for a stream as a result of a
  WINDOW_UPDATE frame the remainder of the request is now discarded
- The connection flow control window is, effectively, reduced as soon as
  an allocation is made rather than waiting until after the Stream is
  released. This is an improvement over the previous approach where over
  allocation was possible.
- The loop in reserveWindowSize is removed
---
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 316 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |   3 +-
 webapps/docs/changelog.xml |   6 +
 5 files changed, 154 insertions(+), 202 deletions(-)

diff --git a/java/org/apache/coyote/http2/AbstractStream.java 
b/java/org/apache/coyote/http2/AbstractStream.java
index c7374b6..6a825c2 100644
--- a/java/org/apache/coyote/http2/AbstractStream.java
+++ b/java/org/apache/coyote/http2/AbstractStream.java
@@ -40,6 +40,9 @@ abstract class AbstractStream {
 private final Set childStreams = 
Collections.newSetFromMap(new ConcurrentHashMap<>());
 private long windowSize = 
ConnectionSettingsBase.DEFAULT_INITIAL_WINDOW_SIZE;
 
+private volatile int connectionAllocationRequested = 0;
+private volatile int connectionAllocationMade = 0;
+
 
 AbstractStream(Integer identifier) {
 this.identifier = identifier;
@@ -154,6 +157,30 @@ abstract class AbstractStream {
 }
 
 
+final int getConnectionAllocationRequested() {
+return connectionAllocationRequested;
+}
+
+
+final void setConnectionAllocationRequested(int 
connectionAllocationRequested) {
+
log.debug(sm.getString("abstractStream.setConnectionAllocationRequested", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationRequested), 
Integer.toString(connectionAllocationRequested)));
+this.connectionAllocationRequested = connectionAllocationRequested;
+}
+
+
+final int getConnectionAllocationMade() {
+return connectionAllocationMade;
+}
+
+
+final void setConnectionAllocationMade(int connectionAllocationMade) {
+log.debug(sm.getString("abstractStream.setConnectionAllocationMade", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationMade), 
Integer.toString(connectionAllocationMade)));
+this.connectionAllocationMade = connectionAllocationMade;
+}
+
+
 abstract String getConnectionId();
 
 abstract int getWeight();
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 976f2ad..6a0b08a 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -20,10 +20,9 @@ import java.io.EOFException;
 import java.io.IOException;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
+import java.util.Collections;
 import java.util.HashSet;
 import java.util.Iterator;
-import java.util.Map;
-import java.util.Map.Entry;
 import java.util.Queue;
 import java.util.Set;
 import java.util.TreeSet;
@@ -132,7 +131,7 @@ class Http2UpgradeHandler extends AbstractStream implements 
InternalHttpUpgradeH
 private final AtomicInteger nextLocalStreamId = new AtomicInteger(2);
 private final PingManager pingManager = getPingManager();
 private volatile int newStreamsSinceLastPrune = 0;
-private final Map backLogStreams = new 
ConcurrentHashMap<>();
+private final Set backLogStreams = 
Collections.newSetFromMap(new ConcurrentHashMap<>());
 private long backLogSize = 0;
 // The time at which the connection will timeout unless data arrives before
 // then. -1 means no timeout.
@@ -873,101 +872,81 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // this thread until after this thread enters wait()
 int allocation = 0;
 synchronized (stream) {
-do {
-synchronized (this) {
-if (!stream.canWrite()) {
-
stream.doStreamCancel(sm.getString("upgradeHandler.stream.notWritable",
-stream.getConnectionId(), 
stream.getIdAsString()), Http2Error.STREAM_CLOSED);
-}
-lo

[Bug 65517] upgrade to axis2-adb 1.8.0 to address CVE-2020-0822

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65517

--- Comment #3 from Jeehong Min  ---
I filed the original bug.  Afterwards, I realized that I made a mistake when I
was tracing dependencies with CVEs.  Tomcat does not have any dependencies on
axis2-adb.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
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 (5ca5269 -> 5125805)

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from 5ca5269  Fix typo
 new c3d9cf8  Fix a potential cause of intermittent test failure
 new a26978b  Move debug statement inside sync block
 new f6fa2f7  Make synchronized as method assumes a lock is held on the 
instance
 new 5125805  Refactor allocations for the connection flow control window

The 4 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 317 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |  12 +-
 .../apache/coyote/http2/TestHttp2Section_5_3.java  |   5 +
 webapps/docs/changelog.xml |  10 +
 6 files changed, 168 insertions(+), 207 deletions(-)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 01/04: Fix a potential cause of intermittent test failure

[markt]

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

commit c3d9cf805487595cb0f4cda474c5cd1a91f097e9
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:47:35 2021 +0100

Fix a potential cause of intermittent test failure
---
 test/org/apache/coyote/http2/TestHttp2Section_5_3.java | 5 +
 1 file changed, 5 insertions(+)

diff --git a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java 
b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
index d85c620..6001b3e 100644
--- a/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
+++ b/test/org/apache/coyote/http2/TestHttp2Section_5_3.java
@@ -177,6 +177,11 @@ public class TestHttp2Section_5_3 extends Http2TestBase {
 output.clearTrace();
 }
 
+// Need to give both server side threads enough time to request an
+// allocation from the connection flow control window before sending
+// the next window update.
+Thread.sleep(1000);
+
 sendWindowUpdate(0, 1024);
 parser.readFrame(true);
 

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 02/04: Move debug statement inside sync block

[markt]

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

commit a26978b45d165e429c44c58022a4a8db93841da6
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:52:42 2021 +0100

Move debug statement inside sync block

Ensures that the values logged are consistent with the values processed.
---
 java/org/apache/coyote/http2/WindowAllocationManager.java | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/coyote/http2/WindowAllocationManager.java 
b/java/org/apache/coyote/http2/WindowAllocationManager.java
index 96016cc..6c824a5 100644
--- a/java/org/apache/coyote/http2/WindowAllocationManager.java
+++ b/java/org/apache/coyote/http2/WindowAllocationManager.java
@@ -172,12 +172,13 @@ class WindowAllocationManager {
 
 
 private void notify(int notifyTarget) {
-if (log.isDebugEnabled()) {
-log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
-stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
-}
 
 synchronized (stream) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("windowAllocationManager.notify", 
stream.getConnectionId(),
+stream.getIdAsString(), Integer.toString(waitingFor), 
Integer.toString(notifyTarget)));
+}
+
 if ((notifyTarget & waitingFor) > NONE) {
 // Reset this here so multiple notifies (possible with a
 // backlog containing multiple streams and small window 
updates)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 04/04: Refactor allocations for the connection flow control window

[markt]

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

commit 51258057032d7f7fcac2c9416bebab45d784053f
Author: Mark Thomas 
AuthorDate: Wed Sep 15 14:12:26 2021 +0100

Refactor allocations for the connection flow control window

There are multiple related changes in this commit
- The BackLog tracker object is removed and replaced with fields on
  AbstractStream.
- If an incomplete allocation is made for a stream as a result of a
  WINDOW_UPDATE frame the remainder of the request is now discarded
- The connection flow control window is, effectively, reduced as soon as
  an allocation is made rather than waiting until after the Stream is
  released. This is an improvement over the previous approach where over
  allocation was possible.
- The loop in reserveWindowSize is removed
# Conflicts:
#   java/org/apache/coyote/http2/Http2UpgradeHandler.java
#   webapps/docs/changelog.xml
---
 java/org/apache/coyote/http2/AbstractStream.java   |  27 ++
 .../apache/coyote/http2/Http2UpgradeHandler.java   | 315 -
 .../apache/coyote/http2/LocalStrings.properties|   4 +-
 .../coyote/http2/WindowAllocationManager.java  |   3 +-
 webapps/docs/changelog.xml |  10 +
 5 files changed, 157 insertions(+), 202 deletions(-)

diff --git a/java/org/apache/coyote/http2/AbstractStream.java 
b/java/org/apache/coyote/http2/AbstractStream.java
index deaaa6a..ed0e587 100644
--- a/java/org/apache/coyote/http2/AbstractStream.java
+++ b/java/org/apache/coyote/http2/AbstractStream.java
@@ -41,6 +41,9 @@ abstract class AbstractStream {
 Collections.newSetFromMap(new 
ConcurrentHashMap());
 private long windowSize = 
ConnectionSettingsBase.DEFAULT_INITIAL_WINDOW_SIZE;
 
+private volatile int connectionAllocationRequested = 0;
+private volatile int connectionAllocationMade = 0;
+
 
 AbstractStream(Integer identifier) {
 this.identifier = identifier;
@@ -155,6 +158,30 @@ abstract class AbstractStream {
 }
 
 
+final int getConnectionAllocationRequested() {
+return connectionAllocationRequested;
+}
+
+
+final void setConnectionAllocationRequested(int 
connectionAllocationRequested) {
+
log.debug(sm.getString("abstractStream.setConnectionAllocationRequested", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationRequested), 
Integer.toString(connectionAllocationRequested)));
+this.connectionAllocationRequested = connectionAllocationRequested;
+}
+
+
+final int getConnectionAllocationMade() {
+return connectionAllocationMade;
+}
+
+
+final void setConnectionAllocationMade(int connectionAllocationMade) {
+log.debug(sm.getString("abstractStream.setConnectionAllocationMade", 
getConnectionId(), getIdAsString(),
+Integer.toString(this.connectionAllocationMade), 
Integer.toString(connectionAllocationMade)));
+this.connectionAllocationMade = connectionAllocationMade;
+}
+
+
 abstract String getConnectionId();
 
 abstract int getWeight();
diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 52cb94c..ef9168a 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -23,13 +23,11 @@ import java.nio.charset.StandardCharsets;
 import java.util.Collections;
 import java.util.HashSet;
 import java.util.Iterator;
-import java.util.Map.Entry;
 import java.util.Queue;
 import java.util.Set;
 import java.util.TreeSet;
 import java.util.concurrent.ConcurrentHashMap;
 import java.util.concurrent.ConcurrentLinkedQueue;
-import java.util.concurrent.ConcurrentMap;
 import java.util.concurrent.ConcurrentNavigableMap;
 import java.util.concurrent.ConcurrentSkipListMap;
 import java.util.concurrent.atomic.AtomicInteger;
@@ -137,7 +135,7 @@ class Http2UpgradeHandler extends AbstractStream implements 
InternalHttpUpgradeH
 private final AtomicInteger nextLocalStreamId = new AtomicInteger(2);
 private final PingManager pingManager = new PingManager();
 private volatile int newStreamsSinceLastPrune = 0;
-private final ConcurrentMap backLogStreams 
= new ConcurrentHashMap<>();
+private final Set backLogStreams = 
Collections.newSetFromMap(new ConcurrentHashMap());
 private long backLogSize = 0;
 // The time at which the connection will timeout unless data arrives before
 // then. -1 means no timeout.
@@ -876,101 +874,81 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // this thread until after this thread enters wait()
 int allocation = 0;
 synchronized (stream) {
-do {
-synchronized (this) {
-

[tomcat] 03/04: Make synchronized as method assumes a lock is held on the instance

[markt]

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

commit f6fa2f71b4a636eb08e8aa48cbc5b7ec23094e86
Author: Mark Thomas 
AuthorDate: Wed Sep 15 13:56:45 2021 +0100

Make synchronized as method assumes a lock is held on the instance
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 4b0eb56..52cb94c 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -1046,7 +1046,7 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 }
 
 
-private int allocate(AbstractStream stream, int allocation) {
+private synchronized int allocate(AbstractStream stream, int allocation) {
 if (log.isDebugEnabled()) {
 log.debug(sm.getString("upgradeHandler.allocate.debug", 
getConnectionId(),
 stream.getIdAsString(), Integer.toString(allocation)));

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65517] upgrade to axis2-adb 1.8.0 to address CVE-2020-0822

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65517

--- Comment #4 from Mikko Suonio  ---
I would like Tomcat developers to state clearly that this is not a valid
vulnerability. This would make it easier for Tomcat users to dismiss the issue
detected by vulnerability analysis of their software.

Also, it would be excellent, if you could communicate these inaccuracies to
NIST NVD. This might help to correct the CVE description faster and reduce the
impact to Tomcat users. If this is not possible, users could point NIST staff
to the issue description on Tomcat site and forums, if available.

Thank you for the quick response. I do not understand why Tomcat was associated
with this CVE.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1893363 - in /tomcat/site/trunk: docs/security-10.html docs/security-8.html docs/security-9.html xdocs/security-10.xml xdocs/security-8.xml xdocs/security-9.xml

[markt]

Author: markt
Date: Wed Sep 15 17:51:53 2021
New Revision: 1893363

URL: http://svn.apache.org/viewvc?rev=1893363&view=rev
Log:
Publish CVE-2021-41079

Modified:
tomcat/site/trunk/docs/security-10.html
tomcat/site/trunk/docs/security-8.html
tomcat/site/trunk/docs/security-9.html
tomcat/site/trunk/xdocs/security-10.xml
tomcat/site/trunk/xdocs/security-8.xml
tomcat/site/trunk/xdocs/security-9.xml

Modified: tomcat/site/trunk/docs/security-10.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-10.html?rev=1893363&r1=1893362&r2=1893363&view=diff
==
--- tomcat/site/trunk/docs/security-10.html (original)
+++ tomcat/site/trunk/docs/security-10.html Wed Sep 15 17:51:53 2021
@@ -2,7 +2,7 @@
 Apache Tomcat® - Apache Tomcat 10 
vulnerabilitieshttp://tomcat.apache.org/";>Apache 
Tomcat®https://www.apache.org/foundation/contributing.html"; target="_blank" 
class="pull-left">https://www.apache.org/images/SupportApache-small.png"; class="support-asf" 
alt="Support Apache">http://www.apache.org/"; target="_blank" class="pull-left">https://www.google.com/search"; method="get">GOhttps://www.apache.org/events/current-event.html";>https://www.apache.org/events/current-event-234x60.png"; alt="Next ASF 
event">
   Save the date!
 Apache TomcatHomeTaglibsMaven 
PluginDownloadWhich version?https://tomcat.apache.org/download-10.cgi";>Tomcat 10https://tomcat.apache.org/download-90.cgi";>Tomcat 9https://tomcat.apache.org/download-80.cgi";>Tomcat 8https://tomcat.apache.org/download-migration.cgi";>Tomcat Migration Tool 
for Jakarta EEhttps://tomcat.apache.org/download-connectors.cgi";>Tomcat 
Connectorshttps://tomcat.apache.org/download-native.cgi";>Tomcat 
Nativehttps://tomcat.apache.org/download-taglibs.cgi";>Taglibshttps://archive.apache.org/dist/tomcat/";>ArchivesDocumentationTomcat 10.1 (alpha)Tomcat 10.0Tomcat 9.0Tomcat 8.5Tomcat ConnectorsTomcat Nativehttps://cwiki.apache.org/confluence/display/TOMCAT";>WikiMigration GuidePresentationshttps://cwiki.apache.org/confluence/x/Bi8lBg";>SpecificationsProblems?Security ReportsFind helphttps://cwiki.apache.org/confluence/display/TOMCAT/FAQ";>FAQMailing ListsBug 
DatabaseIRC
 Get InvolvedOverviewSource 
codeBuildbothttps://cwiki.apache.org/confluence/x/vIPzBQ";>TranslationsToolsMediahttps://twitter.com/theapachetomcat";>Twitterhttps://www.youtube.com/c/ApacheTomcatOfficial";>YouTubehttps://blogs.apache.org/tomcat/";>BlogMiscWho We Arehttps://www.redbubble.com/people/comdev/works/30885254-apache-tomcat";>SwagHeritagehttp://www.apache.org";>Apache HomeResourcesContactLegalhttps://www.apache.org/foundation/contributing
 .html">Support Apachehttps://www.apache.org/foundation/sponsorship.html";>Sponsorshiphttp://www.apache.org/foundation/thanks.html";>Thankshttp://www.apache.org/licenses/";>LicenseContentTable of Contents
-Apache Tomcat 10.x 
vulnerabilitiesFixed in 
Apache Tomcat 10.0.7Fixed 
in Apache Tomcat 10.0.6Fixed in Apache Tomcat 
10.0.5Fixed in Apache 
Tomcat 10.0.2Fixed in 
Apache Tomcat 10.0.0-M10Fixed in Apache Tomcat 
10.0.0-M8Fixed in 
Apache Tomcat 10.0.0-M7Fixed in Apache Tomcat 
10.0.0-M6Fixed in 
Apache Tomcat 10.0.0-M5
+Apache Tomcat 10.x 
vulnerabilitiesFixed in 
Apache Tomcat 10.0.7Fixed 
in Apache Tomcat 10.0.6Fixed in Apache Tomcat 
10.0.5Fixed in Apache 
Tomcat 10.0.4Fixed in 
Apache Tomcat 10.0.2Fixed in Apache Tomcat 
10.0.0-M10Fixed in 
Apache Tomcat 10.0.0-M8Fixed in Apache Tomcat 
10.0.0-M7Fixed in 
Apache Tomcat 10.0.0-M6Fixed in Apache Tomcat 
10.0.0-M5
 Apache Tomcat 10.x 
vulnerabilities
 This page lists all security vulnerabilities fixed in released versions
of Apache Tomcat 10.x. Each vulnerability is given a
@@ -111,6 +111,33 @@
 
 Affects: 10.0.3 to 10.0.4
 
+  10 
March 2021 Fixed in Apache Tomcat 10.0.4
+
+Note: The issue below was fixed in Apache Tomcat 10.0.3 but the
+   release vote for the 10.0.3 release candidate did not pass. Therefore,
+   although users must download 10.0.4 to obtain a version that includes a
+   fix for these issues, version 10.0.3 is not included in the list of 
+   affected versions.
+
+Important: Denial of Service
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41079"; 
rel="nofollow">CVE-2021-41079
+
+When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a
+  specially crafted packet could be used to trigger an infinite loop
+  resulting in a denial of service.
+
+This was fixed with commit
+   https://github.com/apache/tomcat/commit/34115fb3c83f6cd97772232316a492a4cc5729e0";>34115fb3.
+
+This issue was first reported to the Apache Tomcat Security Team by
+   Thomas Wozenilek on 26 February 2021 but could not be confirmed. A
+   speculative fix was applied on 3 March 2021. On 14 September 2021 David
+   Frankson of Infinite Campus independently reported the issue and 
in

[SECURITY] CVE-2021-41079 Apache Tomcat DoS

[Mark Thomas]

CVE-2021-41079 Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.0.0-M1 to 10.0.2
Apache Tomcat 9.0.0-M1 to 9.0.43
Apache Tomcat 8.5.0 to 8.5.63

Description:
When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a 
specially crafted packet could be used to trigger an infinite loop 
resulting in a denial of service.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 10.0.4 or later
- Upgrade to Apache Tomcat 9.0.44 or later
- Upgrade to Apache Tomcat 8.5.64 or later

Note: This issue was fixed in Apache Tomcat 10.0.3 but the release vote 
for the 10.0.3 release candidate did not pass. Therefore, although users 
must download 10.0.4 to obtain a version that includes a fix for this 
issue, version 10.0.3 is not included in the list of affected versions.


Credit:
The Apache Tomcat Security Team would like to thank:
- Thomas Wozenilek for originally reporting this issue
- David Frankson of Infinite Campus for providing a test case that
  reproduced the issue.

History:
2021-09-15 Original advisory

References:
[1] https://tomcat.apache.org/security-10.html
[2] https://tomcat.apache.org/security-9.html
[3] https://tomcat.apache.org/security-8.html

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org