You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Doug Whitfield <dw...@perforce.com> on 2023/01/09 16:55:55 UTC
Question about Redisson
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<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=2021-common&utm_content=email-signature-link>
P: +1 612.517.2100 <tel:>
Visit us on: LinkedIn<https://www.linkedin.com/company/perforce?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2021-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=2021-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=2021-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=2021-common&utm_content=email-signature-link>
The Star Tribune recognizes Perforce as a Top Workplace in Minnesota. Read more ><https://www.startribune.com/top-workplaces/571419751/>
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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Doug,
On 1/12/23 15:51, Doug Whitfield wrote:
>> 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.
Thank you very much. We do appreciate it, since we really do try to
provide decent community support here.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Question about Redisson
Posted by Doug Whitfield <dw...@perforce.com>.
>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.
Re: Question about Redisson
Posted by Mark Thomas <ma...@apache.org>.
Doug,
There were a couple of questions in my original response it would be
useful to get answers to.
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.
Mark
On 10/01/2023 19:09, Doug Whitfield wrote:
> 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.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Question about Redisson
Posted by Doug Whitfield <dw...@perforce.com>.
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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <us...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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.
>
>
Re: Question about Redisson
Posted by Doug Whitfield <dw...@perforce.com>.
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 <ma...@apache.org>
Date: Monday, January 9, 2023 at 12:12
To: users@tomcat.apache.org <us...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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.
Re: Question about Redisson
Posted by Mark Thomas <ma...@apache.org>.
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://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=2021-common&utm_content=email-signature-link>
> P: +1 612.517.2100 <tel:>
> Visit us on: LinkedIn<https://www.linkedin.com/company/perforce?utm_leadsource=email-signature&utm_source=outlook-direct-email&utm_medium=email&utm_campaign=2021-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=2021-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=2021-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=2021-common&utm_content=email-signature-link>
>
> The Star Tribune recognizes Perforce as a Top Workplace in Minnesota. Read more ><https://www.startribune.com/top-workplaces/571419751/>
>
>
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org