Website inconsistency

[Doug Whitfield]

Hi Folks,

On the left sidebar of the website the download is for “Tomcat 10” while the 
Documentation is for “Tomcat 10.1”. Now, between Download and Documentation 
things are consistent.

I don’t think this is strictly speaking wrong, but I don’t see any good reason 
for it and I do think it is a bit confusing. Is there a good reason that I am 
missing?

Best Regards,

Douglas Whitfield | Enterprise Architect




This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: HTTP2 : WINDOW_UPDATE not sent on stream level

[Doug Whitfield]

Hi Mark,

In the newly opened bug report about this 
(https://bz.apache.org/bugzilla/show_bug.cgi?id=65773), you noted that logging 
at level FINE would show what is happening.

What exactly are we looking at when it says it “Swallowed [0] bytes”? I can get 
more data, but at this point, I just want to understand the log sample:

Time: 2022-01-12 03:44:42.895, Level: FINE, Logger: 
org.apache.coyote.http2.Http2Parser
org.apache.coyote.http2.Http2Parser swallow
- Connection [54], Stream [2076417], Swallowed [0] bytes

Best Regards,
--

Doug Whitfield | Enterprise Architect, 
OpenLogic<https://www.openlogic.com/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
Perforce 
Software<http://www.perforce.com/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
Visit us on: 
LinkedIn<https://www.linkedin.com/company/perforce?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
 | 
Twitter<https://twitter.com/perforce?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
 | 
Facebook<https://www.facebook.com/perforce/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
 | 
YouTube<https://www.youtube.com/user/perforcesoftware?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>



From: Mark Thomas 
Date: Monday, January 10, 2022 at 1:52 AM
To: users@tomcat.apache.org 
Subject: Re: HTTP2 : WINDOW_UPDATE not sent on stream level
On 10/01/2022 07:23, Arshiya Shariff wrote:
> Thank you for the response Mark .
>
> Yes, with the default window size the requests process fine .
>
> We were just attempting to reproduce the original issue that we are facing in 
> production with version 9.0.38 where few connections go unresponsive for few 
> seconds around the same time i.e. tomcat is able to receive the 
> headers/partial data, but not responding back with window_update or sending 
> ping frames and then after sometime tomcat sends PING frame and the 
> connection processes further requests successfully . The GC looks fine at 
> that time.
>
> Could there be any reasons that can cause this ? Please let us know.

The behaviour you saw with 9.0.38 is likely to be a known bug that is
fixed in 9.0.56. From the changelog:

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D65179&data=04%7C01%7Cdwhitfield%40perforce.com%7C8c32c6efff5f492ddb9e08d9d40e1007%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637773979411880749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yQG8pgfLrw6ED9tbG5m5JvKuhEljcsIC4RpvIqmPEl8%3D&reserved=0
Ensure that the connection level flow control window from the client to
the server is updated when handling DATA frames received for completed
streams else the flow control window may become exhausted.

It could also be:

Correct bugs in the HTTP/2 connection flow control management that meant
it was possible for a connection to stall waiting for a connection flow
control window update that had already arrived. Any streams on that
connection that were trying to write when this happened would time out.


I think the first entry is more likely but it could be either.

If you want to be reasonably sure which it is, test with versions
9.0.44, 9.0.45, 9.0.48 and 9.0.50.

If you want to be really sure, build Tomcat from source for the commits
just before and just after each fix and test with those builds.

Mark


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Question about Redisson

[Doug Whitfield]

Hi Tomcat Community,

We are seeing and issue that manifests as a cross session “bleeding” scenario. 
The issue is this:

1. User A make a new request and the request goes to pod A and gets Session1
2. User A's next request then gets redirected to pod B. The request is 
processed using Session1
3. User B now makes a new request and the request goes to pod B and instead of 
getting a new session, User B gets the same Session1 as User A

We are using https://github.com/redisson/redisson for caching with Tomcat 
9.0.58. Given the fixed bugs in the Tomcat changelog, I have suggested trying 
9.0.66 or later. However, this suggestion has been met with resistance.

For those unfamiliar with Redisson, I think the most important high-level piece 
from their docs is this:
“Redisson's Tomcat Session Manager allows you to store sessions of Apache 
Tomcat in Redis. It empowers you to distribute requests across a cluster of 
Tomcat servers. This is all done in non-sticky session management backed by 
Redis.”

I believe we could take a heap dump and get the answer, but at the moment that 
isn’t something we want to do.

My question, at the moment, is pretty simple. How does this interact with 
Tomcat? Would the session management bugs in Tomcat apply?

Best Regards,

Douglas Whitfield | Enterprise Architect, 
OpenLogic
Perforce 
Software
P: +1 612.517.2100 
Visit us on: 
LinkedIn
 | 
Twitter
 | 
Facebook
 | 
YouTube

The Star Tribune recognizes Perforce as a Top Workplace in Minnesota. Read more 
>



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: Question about Redisson

[Doug Whitfield]

Interesting. I’m not on the marketing team. What comments are you talking 
about? I can certainly try to get them removed.

We don’t fork software which means when we find a bug we always work with 
upstream to get it fixed. The idea that we don’t work with the community when 
necessary is an insane for anything to put on our website (doesn’t mean I have 
any power to fix the copy though).


Douglas Whitfield | Enterprise Architect, 
OpenLogic<https://www.openlogic.com/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>



From: Mark Thomas 
Date: Monday, January 9, 2023 at 12:12
To: users@tomcat.apache.org 
Subject: Re: Question about Redisson
Given the disparaging comments OpenLogic makes about obtaining support
for open source projects from a community forum, it is more than a tad
ironic to see an OpenLogic Enterprise Architect asking for help here.

I suggest that OpenLogic replace the text on their home page with
something rather more honest that reflects that OpenLogic turns to the
community forum when their Enterprise Architects need answers (which
you'll find in-line below).

On 09/01/2023 16:55, Doug Whitfield wrote:
> Hi Tomcat Community,
>
> We are seeing and issue that manifests as a cross session “bleeding” 
> scenario. The issue is this:
>
> 1. User A make a new request and the request goes to pod A and gets Session1
> 2. User A's next request then gets redirected to pod B. The request is 
> processed using Session1
> 3. User B now makes a new request and the request goes to pod B and instead 
> of getting a new session, User B gets the same Session1 as User A
>
> We are using https://github.com/redisson/redisson for caching with Tomcat 
> 9.0.58. Given the fixed bugs in the Tomcat changelog, I have suggested trying 
> 9.0.66 or later. However, this suggestion has been met with resistance.

Which bugs fixed between 9.0.58 and 9.0.66 do you believe are relevant
to this issue?

The only possibility I could see was "Improve the recycling of Processor
objects to make it more robust" which is the fix for CVE-2021-43980. You
will only hit that issue in specific circumstances that I do not wish to
make public. If you can provide OS/Java version info and the Connector
(and Executor if used) configuration from server.xml I can tell you if
you are likely to be affected by that issue.

> For those unfamiliar with Redisson, I think the most important high-level 
> piece from their docs is this:
> “Redisson's Tomcat Session Manager allows you to store sessions of Apache 
> Tomcat in Redis. It empowers you to distribute requests across a cluster of 
> Tomcat servers. This is all done in non-sticky session management backed by 
> Redis.”
>
> I believe we could take a heap dump and get the answer, but at the moment 
> that isn’t something we want to do.
>
> My question, at the moment, is pretty simple. How does this interact with 
> Tomcat? Would the session management bugs in Tomcat apply?

Almost certainly.

There are lots of ways to trigger response mix-up. The primary cause is
application bugs. This usually takes the form of the application
retaining a reference to the request and/or response object beyond the
end of processing for a single request/response. Tomcat recycles request
and response objects so these objects can be being used for a new
request while the application is still using them for the old request.

The next most frequent cause is Tomcat bugs. Generally, these take the
form of the request/response objects not being recycled correctly and
typically result in the same request and/or response object being used
for multiple concurrent requests/responses. Any bug of this nature will
be treated as a security issue so a CVE reference will be allocated and
it will be listed on the security pages.

Any session manager is going to susceptible to both types of bug
described above.

In theory, session mix-up could occur within a session manager but I
don't recall ever seeing a bug like that either in the Tomcat provided
managers or the various 3rd party managers like Redisson.

HTH,

Mark


>
> Best Regards,
>
> Douglas Whitfield | Enterprise Architect, 
> OpenLogic<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openlogic.com%2F%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-link&data=05%7C01%7Cdwhitfield%40perforce.com%7Cd109a4f9f10441e5895c08daf26d103e%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638088847521348881%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KrMLo05t741I8SJsL24Fgu7gAR%2BUBfNVhbEVikiqZRU%3D&reserved=0>
> Perforce 
> Software<

Re: Question about Redisson

[Doug Whitfield]

First off, thanks for the link. I’m bringing this up with my manager who is 
much more likely to be able to make some headway with the marketing folks. 
There’s surely a marketing friendly way to say “Pay for SLA”.

> Are you able to reproduce the same problem with a non-Redisson-based
> segmented cluster, such as one using Tomcat's BackupManager?

No. I told them this was going to be the answer. In fact, this was our answer, 
but customer really, really thinks it is a Tomcat issue. Maybe it is, but I 
haven’t personally seen the evidence.

In any case, having the words in print rather than in prediction might help get 
us something more useful, like I think a heap dump might be.

Thanks!


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: Question about Redisson

[Doug Whitfield]

>Also, Chris's suggesiton to look at
>org.apache.catalina.connector.RECYCLE_FACADES is a good first step. Note
> that the value you need for that may not be what you expect. It needs to
> be "true" whereas I read the name and think it should be "false" to
> disable recycling.




Thanks for coming back to this. This is actually exactly where I started, but I 
have not heard back, which is why I didn’t address it.

BTW, can’t make any promises since not sure how far up things need to go, but 
my initial suggestions to marketing about changing that text on the landing 
page were met very positively. I’m OOO next week, so suspect it’ll be a while 
before you hear anything back, but this might get fixed next week.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

GOAWAY sent on 404 with large payload in http2

[Doug Whitfield]

Hi folks,

It is unclear if this is a Tomcat issue, a protocol issue, or something else. I 
would like some help figuring out if it is a Tomcat issue and then resolving 
the issue if it is. We have seen this issue in Tomcat 9.0.38 through 9.0.43.

For a handful of requests, Tomcat sends GOAWAY with below reason :
GOAWAY with FRAME_SIZE_ERROR : The payload is [2105376] bytes long but the 
maximum frame size is [16384]
The payload size here from the user point of view is around 55 KB, but we’ve 
tested similar payload sizes with similar results.



Steps to reproduce:
1. client sends an request of size 90KB to an unknown URL (means 
servlet-context was not deployed) towards tomcat.
2. Tomcat sends 404 page not found which is expected.
3. Tomcats sends RST_STREAM with CANCEL as reason.
4. Tomcat doesn't send WINDOW_UPDATE after this.
5. Client was not able to send further DATA frames towards Tomcat.
6. Client is able to send only HEADERS (to an deployed URL), but no DATA, all 
requests on that connection fails.
The above flow works properly when client sends an request to an correct 
deployed URL. The obvious response is to just use the correct URLs in 
applications, but we want to make sure this is not a security vulnerability.

All properties are the tomcat defaults.
Here are the connector details:
Connector connector = new Connector();
connector.setPort(1080);
Http2Protocol http2Protocol = new Http2Protocol();
connector.addUpgradeProtocol( http2Protocol );
tomcat.setConnector(connector);


Windows 10 (but also reproduced on Red Hat 7.4)
Processor: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz 1.90GHz
RAM:16 GB
System Type : 64 bit

How we reproduced:
With JMeter as simulation client, on configuring 700 threads (700 connections) 
to connect towards Tomcat Server 9.0.43 embedded in the application and on 
sending 20 requests per second with payload of 55KB (same request with just one 
json value sent uniquely via the Random number generator) and on running the 
test in an infinite loop , few requests are getting timed out . On analyzing 
the PCAP for the requests that timed-out we see that tomcat sends GOAWAY with  
PROTOCOL ERROR / FRAME_SIZE_ERROR .

Client:
JMeter 5.3 with additional HTTP2 sampler and Xmx 5g.
No of threads: 700
Ramp-up period: 10 seconds
Loop: Infinite
Payload size: around 55KB
Constant Throughput Timer added to limit the tps to 20.
Random Variable Generator added to the JSON request to uniquely identify for 
which request the exception is printed and to map it in the PCAP collected .
Response Timeout : 5000 ms

SERVER:
The input requests are processed asynchronously with 40 threads.




Are there any logs I should look at, and at what log level? There wasn’t 
anything obviously useful at FINER.

Please let me know if there is any additional information that would be useful.


Best Regards,
--

Doug Whitfield | Enterprise Architect, 
OpenLogic<https://www.openlogic.com/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
Perforce 
Software<http://www.perforce.com/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
Visit us on: 
LinkedIn<https://www.linkedin.com/company/perforce?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
 | 
Twitter<https://twitter.com/perforce?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
 | 
Facebook<https://www.facebook.com/perforce/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
 | 
YouTube<https://www.youtube.com/user/perforcesoftware?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>




This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: GOAWAY sent on 404 with large payload in http2

[Doug Whitfield]

Regarding the email thread with this title: “Embedded Tomcat 9.0.43 : 
WINDOW_UPDATE not sent when receiving http2 requests over unknown url”

That looks exactly like our issue, but with slightly different numbers.

From: Doug Whitfield 
Date: Tuesday, March 9, 2021 at 4:02 PM
To: users@tomcat.apache.org 
Subject: GOAWAY sent on 404 with large payload in http2
Hi folks,

It is unclear if this is a Tomcat issue, a protocol issue, or something else. I 
would like some help figuring out if it is a Tomcat issue and then resolving 
the issue if it is. We have seen this issue in Tomcat 9.0.38 through 9.0.43.

For a handful of requests, Tomcat sends GOAWAY with below reason :
GOAWAY with FRAME_SIZE_ERROR : The payload is [2105376] bytes long but the 
maximum frame size is [16384]
The payload size here from the user point of view is around 55 KB, but we’ve 
tested similar payload sizes with similar results.



Steps to reproduce:
1. client sends an request of size 90KB to an unknown URL (means 
servlet-context was not deployed) towards tomcat.
2. Tomcat sends 404 page not found which is expected.
3. Tomcats sends RST_STREAM with CANCEL as reason.
4. Tomcat doesn't send WINDOW_UPDATE after this.
5. Client was not able to send further DATA frames towards Tomcat.
6. Client is able to send only HEADERS (to an deployed URL), but no DATA, all 
requests on that connection fails.
The above flow works properly when client sends an request to an correct 
deployed URL. The obvious response is to just use the correct URLs in 
applications, but we want to make sure this is not a security vulnerability.

All properties are the tomcat defaults.
Here are the connector details:
Connector connector = new Connector();
connector.setPort(1080);
Http2Protocol http2Protocol = new Http2Protocol();
connector.addUpgradeProtocol( http2Protocol );
tomcat.setConnector(connector);


Windows 10 (but also reproduced on Red Hat 7.4)
Processor: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz 1.90GHz
RAM:16 GB
System Type : 64 bit

How we reproduced:
With JMeter as simulation client, on configuring 700 threads (700 connections) 
to connect towards Tomcat Server 9.0.43 embedded in the application and on 
sending 20 requests per second with payload of 55KB (same request with just one 
json value sent uniquely via the Random number generator) and on running the 
test in an infinite loop , few requests are getting timed out . On analyzing 
the PCAP for the requests that timed-out we see that tomcat sends GOAWAY with  
PROTOCOL ERROR / FRAME_SIZE_ERROR .

Client:
JMeter 5.3 with additional HTTP2 sampler and Xmx 5g.
No of threads: 700
Ramp-up period: 10 seconds
Loop: Infinite
Payload size: around 55KB
Constant Throughput Timer added to limit the tps to 20.
Random Variable Generator added to the JSON request to uniquely identify for 
which request the exception is printed and to map it in the PCAP collected .
Response Timeout : 5000 ms

SERVER:
The input requests are processed asynchronously with 40 threads.




Are there any logs I should look at, and at what log level? There wasn’t 
anything obviously useful at FINER.

Please let me know if there is any additional information that would be useful.


Best Regards,
--

Doug Whitfield | Enterprise Architect, 
OpenLogic<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openlogic.com%2F%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-link&data=04%7C01%7Cdwhitfield%40perforce.com%7Cee15754dd3ae42fc792408d8e34709a1%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637509241697963952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LAwM%2FysWiVMfHqiZ4OQ4bw7YB8gq4CZepoIz3mkqduQ%3D&reserved=0>
Perforce 
Software<http://www.perforce.com/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2019-common&utm_content=email-signature-link>
Visit us on: 
LinkedIn<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fperforce%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-link&data=04%7C01%7Cdwhitfield%40perforce.com%7Cee15754dd3ae42fc792408d8e34709a1%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637509241697973946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8%2Fw8RczUp8k4glOsUxCOB5wg8jejdb11wk1xCY%2FtRuA%3D&reserved=0>
 | 
Twitter<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fperforce%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-link&data=04%7C01%7Cdwhitfield%40perforce.com%7Cee15754dd3ae42fc792408d8e3

Re: Embedded Tomcat 9.0.43 : WINDOW_UPDATE not sent when receiving http2 requests over unknown url

[Doug Whitfield]

-Original Message-
From: Mark Thomas 
Sent: Wednesday, March 10, 2021 6:28 PM
To: users@tomcat.apache.org
Subject: Re: Embedded Tomcat 9.0.43 : WINDOW_UPDATE not sent when receiving 
http2 requests over unknown url

On 10/03/2021 05:26, Arshiya Shariff wrote:
> Hi All,
> We are using embedded tomcat version 9.0.43 in our application to transport 
> http/2 packets between 2 systems (h2c connection). All parameters used are 
> the tomcat defaults.
>
> We are facing the below issue :
>
>1.  Tomcat is not sending WINDOW_UPDATE when a request(payload > 65K) is 
> landed on an Unknown URL(which is not deployed as a servlet and not having  a 
> servlet mapping). The same is working when request landed on an known 
> URL(which is deployed as a servlet and has an servlet mapping).
>2.  Tomcat is listening on 1080 port, client is sending packet size of > 
> 65KB, but here tomcat receives only 65KB  and not receiving full DATA, later 
> tomcat sends RST_STREAM, further no WINDOW_UPDATE, after that client is not 
> able to send DATA frames as there is no WINDOW_UPDATE from tomcat.
>
>
> Kindly let us know whether it is a bug or not.

>> Certainly looks like a bug. I'll investigate now...

Just FYI:
I was able to reproduce this issue on 8.5.64 and 9.0.44. I’m going to start 
doing some testing in earlier versions of 8.5 to see if the issue exist there 
as well as far as regressions.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: Embedded Tomcat 9.0.43 : WINDOW_UPDATE not sent when receiving http2 requests over unknown url

[Doug Whitfield]

>I am working on a fix which I expect to be in the releases due out in ~1
> month's time.

Thanks Mark! Is there any chance of a patch being available before then that we 
might be able to backport locally?


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Re: Embedded Tomcat 9.0.43 : WINDOW_UPDATE not sent when receiving http2 requests over unknown url

[Doug Whitfield]

> It exists in all 8.5.x, 9.0.x and 10.0.x versions. It has been there
> since the beginning of HTTP/2 support.

Based on our testing the issue was introduced in 9.0.19 and 8.5.55 (we haven’t 
done any testing on the 10.x branch), which is slightly after the beginning of 
HTTP/2 support. I don’t know if that is helpful information, but I provide it 
in case that it is. Apologies for the second email. We were still discussing 
this internally a bit.

Thanks again for your work on this!


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

What is a reasonable performance degradation?

[Doug Whitfield]

Hi folks,

This feature was added in 9.0.90:
The system property org.apache.catalina.connector.RECYCLE_FACADES will now 
default to true if not specified, which will in turn set the default value for 
the discardFacades connector attribute, thus causing facade objects to be 
discarded by default. (remm)

It makes sense that would cause some performance degradation. We are currently 
seeing *at least* a 5x increase in the number of connections. This doesn’t 
*seem* right, but maybe it is?

We’ve been able to reproduce this in 9.0.90 through 9.0.104. If we set 
RECYCLE_FACADES to false, then we get the performance we have come to expect.

I am trying to get some additional information from the performance team to see 
what exactly they are doing. Perhaps something needs to be updated in their 
code, but in the meantime wondering what others have seen and what folks think 
is a reasonable degradation.

Best Regards,
Douglas Whitfield | Enterprise Architect



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.