/ee6069392752f930c64e160a6a08a9904ffea008
I assume these fixes will be available on 9.0.44 right? I'm unsure
whether they were just applied to the 10.x branch or backported to the
9.x branch as well.
Thanks
*Manuel Dominguez Sarmiento*
On 11/02/2021 10:11, Manuel Dominguez Sarmiento wrote:
Sorry it took so lo
Sorry it took so long to get back to this. @Mark I've just filed bug
65136 as requested:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65136
*Manuel Dominguez Sarmiento*
On 07/01/2021 05:40, Mark Thomas wrote:
On 06/01/2021 21:48, Manuel Dominguez Sarmiento wrote:
Hi, our system consis
? Thanks
*Manuel Dominguez Sarmiento*
The articles in this page will be helpful:
https://java.jiderhamn.se/category/classloader-leaks/
On 12/10/2020 04:19, Mark Thomas wrote:
On 11/10/2020 02:39, Prabhu Gurunathan wrote:
Hi All,
We have an setup where we are using OpenJDK 1.7 and Tomcat 7.0.100 ,
in CentOs 7 Env . and we have many
,
iptables on Linux).
Check the following system properties for clues:
-Dcom.sun.management.jmxremote.port=
-Dcom.sun.management.jmxremote.password.file=
-Dcom.sun.management.jmxremote.access.file=
- Manuel Dominguez Sarmiento
On 06/08/2020 10:13, Kaydo Bramble wrote:
Hi Everyone,
Our
, CDN, buggy browsers, etc.
*Manuel Dominguez Sarmiento*
On 09/06/2020 17:20, Mark Thomas wrote:
Hi all,
An enhancement has been opened to enable response compression by default:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64431
In short, the proposal is to change the default for the
I must say that we're also seeing weird, seemingly random response
delays from Tomcat on HTTP/2
We haven't looked into it at such a low level though. We're currently on
9.0.35 but we've been seeing this on previous versions as well.
*Manuel Dominguez Sarmiento*
On 21/05
Glad that helped!*
Manuel Dominguez Sarmiento*
On 24/04/2020 06:42, OIT Nua wrote:
Thanks, again, for the assistance. Upgrading to 9.0.34 has resolved the issue.
See the following thread:
http://tomcat.10.x6.nabble.com/Uploads-breaking-post-upgrade-to-9-0-31-td5096655.html
And this bug report:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64202
It looks as if upgrading to 9.0.34 should resolve this.
On 21/04/2020 14:55, OIT Nua wrote:
Thanks for resp
What version/build are you using? I believe the was a recent bug that
has been already resolved regarding this on HTTPS.
I have a Tomcat application that accepts file uploads via https. I have had no
problems with file uploads and https in Tomcat versions 7 and 8. Now that we've
ported to T
Base64 would work. I would suggest the error log makes this explicit, so
whoever looks at it knows how to deal with it and diagnose accordingly.
*Manuel Dominguez Sarmiento*
On 15/04/2020 15:37, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Manuel,
On 4/13/20 15
Nevermind. For some reason we had omitted this is already supported by the
ipv6Canonical flag.
RTFM!
Manuel Dominguez Sarmiento
> On 13 Apr 2020, at 20:46, Manuel Dominguez Sarmiento wrote:
>
> Hi, we are in the middle of a thorough review to fully support IPv6 across
> our
rouble, misdiagnosis, missed
records, etc.
Any suggestions?
*Manuel Dominguez Sarmiento*
Thanks Mark. Including the request line (encoded if necessary to avoid
issues with control characters) should definitely help.
Getting through all the way to AccessLogValve would also help, but the
most important bit is improving the error message.
*Manuel Dominguez Sarmiento*
On 13/04/2020
#x27;re on Tomcat 9.0.33
*Manuel Dominguez Sarmiento*
Sorry, I was not aware of that behaviour even when changing the subject.
I'll send a new, separate, unrelated message.
*
Manuel Dominguez Sarmiento*
On 12/04/2020 16:08, Mark Thomas wrote:
Please don't hijack an existing thread. Start a new message for a new
topic. (Replying to a
#x27;re on Tomcat 9.0.33
*Manuel Dominguez Sarmiento*
f any unintended swapping,
which effectively kills throughput whenever the garbage collector
happens to run into memory pages that have been swapped out to disk.
*Manuel Dominguez Sarmiento*
On 01/04/2020 10:06, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jim,
On 3/
Thanks, so we would be able to log this with AccessLogValve using the
following patterns, right?
%{org.apache.coyote.connectionID}r
%{org.apache.coyote.streamID}r
*Manuel Dominguez Sarmiento*
On 31/03/2020 10:28, Mark Thomas wrote:
On 29/03/2020 16:16, Mark Thomas wrote:
On 29/03/2020 15:58
ction/stream id? Can this be logged by AccessLogValve?
*Manuel Dominguez Sarmiento
*
e few and isolated, but still this should be looked into.
Any thoughts?
*Manuel Dominguez Sarmiento*
On 05/02/2020 14:12, Manuel Dominguez Sarmiento wrote:
Our filter is not doing anything fancy (and it has always worked
correctly before we ran into this bug). In pseudo-code:
public doF
Great, I just saw that :-)
On 17/03/2020 11:24, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Manuel.
On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote:
Hi Mark, when is 9.0.32 expected to be released? We've seen this
issue reported by several users, even
Hi Mark, when is 9.0.32 expected to be released? We've seen this issue
reported by several users, even if we haven't run into this particular
case directly (yet)
On 17/03/2020 09:51, Mark Thomas wrote:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64202
Mark
On 17/03/2020 11:46, Srijith Koc
and take the same action(s) on the server-end where you
trust the information being presented.
See comments above.
*Manuel Dominguez Sarmiento*
onnector.RECYCLE_FACADES=true
We do not use this option, so we must be running with the default="false"
See
https://cwiki.apache.org/confluence/x/yColBg#TroubleshootingandDiagnostics-TroubleshootingunexpectedResponsestateproblems
Thanks, I'll read through this.
*Manuel Dominguez Sarmiento*
filter is not meant for detecting internal
proxies within our control (such as Apache front ends or load
balancers), but rather public proxies which are "transparently" (not
really) used via some mobile devices and services.
*
Manuel Dominguez Sarmiento*
-BEGIN PGP SIGNED MESSAGE
delegating to the
actual request, while unwrapXForwardedFor() does what the name suggests,
which is processing X-Forwarded-For to obtain the originating IP before
it hit the detected proxy.
*Manuel Dominguez Sarmiento*
On 05/02/2020 10:28, Mark Thomas wrote:
On 04/02/2020 22:27, Manuel Dominguez
?
*- **Manuel Dominguez Sarmiento*
Thanks Mark. I just wanted to clarify that the issue is not only present
when the request arrives at AccessLogValve, but while the request is
being serviced as well.
We noticed this bug because we were getting random NullPointerExceptions
when trying to do anything
HttpServletRequest.getRemoteAddr() in our servlets.
Should the fix solve this as well?
- Manuel Dominguez Sarmiento
On 03/02/2020 19:24, Mark Thomas wrote:
I haven't fixed this but I can reproduce it easily with the h2spec test
suite. As I have a reproducible test case I'm hopeful I
Hi Mark, thanks for your feedback. Please see below:
On 23/01/2020 13:40, Manuel Dominguez Sarmiento wrote:> Hi, we started
noticing that HttpServletRequest.getRemoteAddr() was
sometimes returning NULL (which is invalid according to the servlet
spec), about 20-50 times per day (we have h
production servers. Any
ideas?
e are using org.apache.catalina.core.AprLifecycleListener as well as
Tomcat Native 1.2.23 on Linux.
We could not find any pointers in the Tomcat Nativ
32 matches
Mail list logo