You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dan Armbrust <da...@gmail.com> on 2023/02/16 00:42:13 UTC
9.0.70 / 9.0.71 regression?
Are there any known regressions / open issues with 9.0.70 or 9.0.71 that could cause
something like the below?
We encountered a very odd issue today, where after upgrading the version of spring-boot
for one of our rest microservices (and getting a newer tomcat) it stopped processing our
calls properly.
But only when it was deployed in an env where the requests were going thru a SSO
authentication layer first, and having a number of extra headers added to the request.
When we tested locally, in an env without the SSO filtering, we didn't see the issue.
It was a very odd problem, it presented to the end user as simply getting 404 errors back
from the service.
Tomcat was indeed sending 404 errors - but our integrated monitoring (datadog) was not
even showing us the proper requests coming in - instead, each request that arrived came
across with some partial (random) URL, which then didn't match any of our services, and
was sent back as a 404.
We haven't yet done any further debugging about where in the tomcat stack the request was
being completely corrupted. I also haven't isolated if it was 9.0.71 or 9.0.70 - 9.0.69
works, and 9.0.71 fails.
Thanks,
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 9.0.70 / 9.0.71 regression?
Posted by Dan Armbrust <da...@gmail.com>.
Thanks for updating - sorry I didn't get a chance to run it down more.
I should be able to do a test in our SSO enabled env this next week with 9.0.73.
Dan
On 2/27/23 4:06 AM, Mark Thomas wrote:
> Looks like this is the issue:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=66488
>
> That you only see the problem when using the SSO layer is consistent with our
> understanding of that bug.
>
> Mark
>
>
> On 16/02/2023 08:37, Mark Thomas wrote:
>> On 16/02/2023 00:42, Dan Armbrust wrote:
>>> Are there any known regressions / open issues with 9.0.70 or 9.0.71 that could cause
>>> something like the below?
>>
>> The closest I can think of is this:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=66388
>>
>> but it is fixed in 9.0.71 and I'd expect it to impact resource lookup (i.e.finding
>> files on disk) but not the request URI since the URL class isn't used got processing
>> the request URI.
>>
>> It would be good to track this down ASAP as we are about to start the next round of
>> releases.
>>
>> Mark
>>
>>
>>>
>>> We encountered a very odd issue today, where after upgrading the version of
>>> spring-boot for one of our rest microservices (and getting a newer tomcat) it stopped
>>> processing our calls properly.
>>>
>>> But only when it was deployed in an env where the requests were going thru a SSO
>>> authentication layer first, and having a number of extra headers added to the request.
>>>
>>> When we tested locally, in an env without the SSO filtering, we didn't see the issue.
>>>
>>> It was a very odd problem, it presented to the end user as simply getting 404 errors
>>> back from the service.
>>>
>>> Tomcat was indeed sending 404 errors - but our integrated monitoring (datadog) was not
>>> even showing us the proper requests coming in - instead, each request that arrived
>>> came across with some partial (random) URL, which then didn't match any of our
>>> services, and was sent back as a 404.
>>>
>>> We haven't yet done any further debugging about where in the tomcat stack the request
>>> was being completely corrupted. I also haven't isolated if it was 9.0.71 or 9.0.70 -
>>> 9.0.69 works, and 9.0.71 fails.
>>>
>>> Thanks,
>>>
>>> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 9.0.70 / 9.0.71 regression?
Posted by Mark Thomas <ma...@apache.org>.
Looks like this is the issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66488
That you only see the problem when using the SSO layer is consistent
with our understanding of that bug.
Mark
On 16/02/2023 08:37, Mark Thomas wrote:
> On 16/02/2023 00:42, Dan Armbrust wrote:
>> Are there any known regressions / open issues with 9.0.70 or 9.0.71
>> that could cause something like the below?
>
> The closest I can think of is this:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=66388
>
> but it is fixed in 9.0.71 and I'd expect it to impact resource lookup
> (i.e.finding files on disk) but not the request URI since the URL class
> isn't used got processing the request URI.
>
> It would be good to track this down ASAP as we are about to start the
> next round of releases.
>
> Mark
>
>
>>
>> We encountered a very odd issue today, where after upgrading the
>> version of spring-boot for one of our rest microservices (and getting
>> a newer tomcat) it stopped processing our calls properly.
>>
>> But only when it was deployed in an env where the requests were going
>> thru a SSO authentication layer first, and having a number of extra
>> headers added to the request.
>>
>> When we tested locally, in an env without the SSO filtering, we didn't
>> see the issue.
>>
>> It was a very odd problem, it presented to the end user as simply
>> getting 404 errors back from the service.
>>
>> Tomcat was indeed sending 404 errors - but our integrated monitoring
>> (datadog) was not even showing us the proper requests coming in -
>> instead, each request that arrived came across with some partial
>> (random) URL, which then didn't match any of our services, and was
>> sent back as a 404.
>>
>> We haven't yet done any further debugging about where in the tomcat
>> stack the request was being completely corrupted. I also haven't
>> isolated if it was 9.0.71 or 9.0.70 - 9.0.69 works, and 9.0.71 fails.
>>
>> Thanks,
>>
>> Dan
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 9.0.70 / 9.0.71 regression?
Posted by Mark Thomas <ma...@apache.org>.
On 16/02/2023 00:42, Dan Armbrust wrote:
> Are there any known regressions / open issues with 9.0.70 or 9.0.71 that
> could cause something like the below?
The closest I can think of is this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66388
but it is fixed in 9.0.71 and I'd expect it to impact resource lookup
(i.e.finding files on disk) but not the request URI since the URL class
isn't used got processing the request URI.
It would be good to track this down ASAP as we are about to start the
next round of releases.
Mark
>
> We encountered a very odd issue today, where after upgrading the version
> of spring-boot for one of our rest microservices (and getting a newer
> tomcat) it stopped processing our calls properly.
>
> But only when it was deployed in an env where the requests were going
> thru a SSO authentication layer first, and having a number of extra
> headers added to the request.
>
> When we tested locally, in an env without the SSO filtering, we didn't
> see the issue.
>
> It was a very odd problem, it presented to the end user as simply
> getting 404 errors back from the service.
>
> Tomcat was indeed sending 404 errors - but our integrated monitoring
> (datadog) was not even showing us the proper requests coming in -
> instead, each request that arrived came across with some partial
> (random) URL, which then didn't match any of our services, and was sent
> back as a 404.
>
> We haven't yet done any further debugging about where in the tomcat
> stack the request was being completely corrupted. I also haven't
> isolated if it was 9.0.71 or 9.0.70 - 9.0.69 works, and 9.0.71 fails.
>
> Thanks,
>
> Dan
>
>
> ---------------------------------------------------------------------
> 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