Doug,
On 1/9/23 15:48, Doug Whitfield wrote:
Interesting. I’m not on the marketing team. What comments are you
talking about? I can certainly try to get them removed.
I think he's talking about this:
"Don’t let your team waste another minute wading through outdated forums
or online documentation to fix, secure, or maintain your
mission-critical infrastructure. Get the technical support you need for
the open source software you use — all in one place."
[https://www.openlogic.com/]
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).
Understood. I think Mark is mostly trying to make a point. He's
obviously willing to engage on the actual question, as well, as you can see.
One thing I wanted to make perfectly clear, which is something I was
confused about when first encountering the term "recycling" when it
comes to certain types of object (like request, response, etc.) in
Tomcat. When the Tomcat documentation says these objects are "recycled"
it really means that they are "re-used". That is, assuming a stable
server where no weird errors occur and the number of connections is
relatively constant, no new Request and Response objects will be created
over time. Instead, they will have their various fields blanked-out for
re-use with a subsequent request. This is a performance optimization to
avoid GC churn, since request and response objects are usually short-lived.
You can get an application to expose its misuse of request- or
response-related objects by disabling this recycling in your
configuration. The result is usually very obvious errors in the log file
due to NPE or similar.
The first step toward debugging IHMO would be to disable recycling and
repeat your tests. I'm assuming given your STR that this is trivially
reproducible?
Are you able to reproduce the same problem with a non-Redisson-based
segmented cluster, such as one using Tomcat's BackupManager?
-chris
From: Mark Thomas <ma...@apache.org>
Date: Monday, January 9, 2023 at 12:12
To: users@tomcat.apache.org <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<http://www.perforce.com/?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2021-common&utm_content=email-signature-link>
P: +1 612.517.2100 <tel:>
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%3D2021-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=ZMeKkPSMa6o8A%2B3azXBDf2P1utxdEo2uePDE6axnQwQ%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%3D2021-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=But%2FTgd0WHc8GT%2FrAh6qE2Mmcw2k4QRr%2BQ7IEPZwnUw%3D&reserved=0>
|
Facebook<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Fperforce%2F%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2021-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=Cu%2FknKyLBL0bbwEmslarpkKGLG5b9qoNsdvswjAT1hA%3D&reserved=0>
|
YouTube<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fuser%2Fperforcesoftware%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2021-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=7cgqrd%2BnPAz6EYOZWscjTIpSP7oPOvZcIPPIVUZp2CE%3D&reserved=0>
The Star Tribune recognizes Perforce as a Top Workplace in Minnesota. Read more
><https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.startribune.com%2Ftop-workplaces%2F571419751%2F&data=05%7C01%7Cdwhitfield%40perforce.com%7Cd109a4f9f10441e5895c08daf26d103e%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638088847521348881%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X34ZSksVpT4YTZlPhzUndmqUCz8Puowb9%2BW8Yueq01o%3D&reserved=0>
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
CAUTION: This email originated from outside of the organization. Do not click
on links or open attachments unless you recognize the sender and know the
content is safe.
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.
