On 2024/06/27 14:47:48 Christopher Schultz wrote: > Rainer, > > On 6/21/24 07:55, Rainer Jung wrote: > > Am 20.06.24 um 17:52 schrieb Christopher Schultz: > >> Francesco, > >> > >> On 6/20/24 09:03, Francesco Chicchiriccò wrote: > >>> On 2024/06/20 12:18:15 Konstantin Kolinko wrote: > >>>> чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò > >>>> <ilgro...@apache.org>: > >>>>> > >>>>> Hi there, > >>>>> at Syncope we usually use the latest Tomcat versions to run a large > >>>>> chunk of our integration tests. > >>>>> > >>>>> In our master branch we relay on Tomcat 10.1.x, and upgrading to > >>>>> 10.1.25 from 10.1.24 went smooth as usual. > >>>>> > >>>>> In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89 > >>>>> everything goes as expected, but with 9.0.90 we are getting the > >>>>> exception [1]. > >>>>> > >>>>> Any idea of what could be changed in 9.0.90 within this regard? > >>>>> Thank you. > >>>>> > >>>>> [1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34 > >>>>> > >>>> > >>>> The "java.lang.IllegalStateException: The request object has been > >>>> recycled and is no longer associated with this facade" message means > >>>> that a Request object has been (illegally) stored and is accessed > >>>> outside of its lifecycle - when the underlying structures and buffers > >>>> have already been recycled and may have been reused to process > >>>> subsequent requests. > >>>> > >>>> Mark wrote: > >>>>> You could try explicitly setting discardFacades to false. > >>>> > >>>> In general, not recommended. > >>>> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors > >>>> > >>>> Calling getScheme() might be safe (as IIRC the info will come from a > >>>> connector configuration), but anything beyond that may lead to either > >>>> false results or to security issues. It would be better to identify > >>>> and fix the underlying cause. > >>> > >>> Are you suggesting there is something to fix on Syncope's or CXF's > >>> code? Or rather on Tomcat? > >> > >> This is a protection that Tomcat is providing to the application. > >> There is no known bug in Tomcat's code. > >> > >> It's not clear to me whether Syncope's or CXF's code is retaining such > >> a reference, but, given the stack trace I would suspect that > >> UserServiceImpl in Syncope's code is where you should start looking. > >> > >>> As I am writing above, we have no issues with Tomcat 9.0.89 nor with > >>> Tomcat 10.1.25. > >> > >> It looks like this change was made in 9.0.90 *only* and was not ported > >> to the other June releases. Honestly, this change should have been > >> made to all active branches... I'm not sure why Rémy only applied it > >> to 9.0.x. > > > > The default value for discardFacades is already "true" in 10.1 and 11 > > and the old system property > > org.apache.catalina.connector.RECYCLE_FACADES no longer exists for > > these. So setting discardFacades to "true" in 9.0.x makes the default > > behavior consistent. > > +1 thanks for pointing this out. This commit was Rémy aligning 9.0.x > with the other active branches, not making it /out/ of alignment. > > > No idea, why the application now shows different behavior for 9.0.x > > and 10.1.x. > Agreed. But wrapping in HttpServletRequestWrapper, using Async, and > performing what the OP described as "multiplex[ing] the incoming request > onto atomic requests, injected to CXF service processing" sounds like a > recipe for retaining references to these objects after they go out of scope.
Hi Chris, the fix mentioned above was exactly addressed to copy (as opposite as reference) the needed values from the original request. While coding the fix, however, I've discovered that the Syncope master branch (run on Tomcat 10.1) was already updated to work this way, while the 3_0_X branch (run on Tomcat 9) was simply not as fresh. Everything is back working as expected, thanks for information. Finally, about: > If your application is retaining a reference to an HttpServletRequest > after the request has been completed, then your application has a bug. > You can tell me it doesn't have a bug, but it does. If you want > information from that request, you should copy it out of the request. I just wanted to reassure you that my intention was not to deny there was an issue, just to explain that probably it was not much about "security and/or privacy". Either way, all is fine again. Regards. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
