You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2024/06/20 10:25:15 UTC
Errors after upgrading to Tomcat 9.0.90
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.
Regards.
[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Francesco,
On 6/21/24 06:02, Francesco Chicchiriccò wrote:
> 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ò <il...@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.
>
> 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.
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.
If you are using an asynchronous request, then you also need to take
care to only use that async request in the way it was intended to be
used. Object lifetimes still apply.
> 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.
Wrapping a request in an HttpServletRequestWrapper does not count as
copying it or the data it contains. That's wrapping it, and you still
have a reference to the original request... through the wrapper.
> We should have a fix ready, going to push it soon.
A fix is good, even if you weren't willing to admit there was a problem
in the first place.
I wonder what the "fix" looks like for a non-bug in this context. I hope
you haven't just made the problem worse.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò <il...@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.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 2024/07/03 20:17:06 Christopher Schultz wrote:
> Francesco,
>
> On 7/2/24 05:44, Francesco Chicchiriccò wrote:
> > 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ò
> >>>>>> <il...@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".
>
> I disagree. If you retain references to those objects, it's entirely
> possible to return data in a response to the wrong user. Or get
> information from a request whose user has changed out from underneath you.
>
> Any time user A and user B can see each other's data, that's a privacy
> and/or security issue in my book.
Hi Chris,
I couldn't agree more with your book, in the general case.
But in this context the caller is one, which is conveying multiple JAX-RS requests onto a single HTTP request, so we don't have user A and user B, only a single user.
Regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Francesco,
On 7/2/24 05:44, Francesco Chicchiriccò wrote:
> 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ò
>>>>>> <il...@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".
I disagree. If you retain references to those objects, it's entirely
possible to return data in a response to the wrong user. Or get
information from a request whose user has changed out from underneath you.
Any time user A and user B can see each other's data, that's a privacy
and/or security issue in my book.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò
> >>>> <il...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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ò
>>>> <il...@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.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Rainer Jung <ra...@kippdata.de>.
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ò
>>> <il...@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. 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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ò <il...@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.
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.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 2024/06/20 12:18:15 Konstantin Kolinko wrote:
> чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò <il...@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?
As I am writing above, we have no issues with Tomcat 9.0.89 nor with Tomcat 10.1.25.
Regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Konstantin Kolinko <kn...@gmail.com>.
чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò <il...@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.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Francesco Chicchiriccò <il...@apache.org>.
Thank you Mark, I will try and let you know.
Is such a change expected for other release lines too? Is there a backing JIRA issue?
Regards.
On 2024/06/20 11:38:28 Mark Thomas wrote:
> That looks like an issue accessing a request/response after the
> request/response has been completed.
>
> Possibly surfaced by this entry from the change log:
>
> 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)
>
> You could try explicitly setting discardFacades to false.
>
> Mark
>
>
> On 20/06/2024 11:25, Francesco Chicchiriccò wrote:
> > 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.
> >
> > Regards.
> >
> >
> > [1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Errors after upgrading to Tomcat 9.0.90
Posted by Mark Thomas <ma...@apache.org>.
That looks like an issue accessing a request/response after the
request/response has been completed.
Possibly surfaced by this entry from the change log:
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)
You could try explicitly setting discardFacades to false.
Mark
On 20/06/2024 11:25, Francesco Chicchiriccò wrote:
> 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.
>
> Regards.
>
>
> [1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org