Re: Errors after upgrading to Tomcat 9.0.90

2024-06-21 Thread Francesco Chicchiriccò
On 2024/06/20 15:52:16 Christopher Schultz wrote:
> 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ò :
> >>>
> >>> 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.

I'd tend to think that such change should be applied to all active branches, 
for consistency.

Is there any issue referencing this change?
 
> This is likely a long-standing bug in your application and it really 
> should be fixed. There is likely a security and/or privacy issue in the 
> application which this error is pointing-out to you.

Nope, nothing of that kind.

Syncope offers an OData-lilke batch feature [1] which implies, in case of 
asynchronous processing request, to multiplex the incoming request onto atomic 
requests, injected to CXF service processing.

The current error derives from the atomic requests being constructed as 
HttpServletRequestWrapper subclasses from the original request: it seems that, 
after the change in Tomcat 9.0.90, this has become problematic - while it is 
still not for Tomcat 10.1.25, Wildfly, Undertow and Payara, against which 
Syncope integration tests are also run.

We should have a fix ready, going to push it soon.

Thank you for your support.
Regards.

[1] https://syncope.apache.org/docs/3.0/reference-guide.html#batch

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



Re: Errors after upgrading to Tomcat 9.0.90

2024-06-21 Thread Rainer Jung

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


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. No idea, why the application now shows different 
behavior for 9.0.x and 10.1.x.


This is likely a long-standing bug in your application and it really 
should be fixed. There is likely a security and/or privacy issue in the 
application which this error is pointing-out to you.


Regards,

Rainer

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