Re: tomcat7 does not log x-forwarded-for
Good morning all,
the answers are [inline].
With kind regards
Frank
Am Dienstag, den 31.03.2020, 15:47 +0100 schrieb Mark Thomas:
> On 31/03/2020 07:26, Frank Tornack wrote:
> > Hello all,
> >
> > I currently have a problem with Tomcat7, or rather a colleague has
> > it.
> > Personally I would like to help him, but I can't find the error
> > myself.
> > We already asked the question on stackoverflow.com and got a good
> > hint,
> > but unfortunately no solving. So I would like to ask for help and
> > support here. I think I am violating the directive of asking a
> > double
> > question, but it is important to me personally to help this
> > colleague.
> > Therefore I am at least honest, the question can also be found at
> > the
> > link:
> > https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-doesnt-work-with-load-balancer
>
> Which at least enables us to find the one key piece of information
> missing in this question, the version of Tomcat being used: 7.0.76
Sorry I forgot to include this information in the mail.
>
> > We run a software that uses Tomcat as application server behind a
> > load
> > balancer. Now we would like to record the initial address of the
> > requests and not the IP of the load balancer. We have used these 3
> > websites for the setup, but unfortunately it does not work. The IPs
> > of
> > the loadbalancers are still written to the access log.
> > https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
> > https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/AccessLogValve.html
> > https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve
> >
> > We used the following configuration for access logging and remote
> > valve:
> > > internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xxx\.9
> > " r
> > emoteIpHeader="X-Forwarded-For" />
>
> The remoteIpHeader setting is unnecessary. That is the default.
The way I understand you, it shouldn't bother? I had added it because I
was not sure about the capitalization.
>
> > > directory="logs"
> > prefix="access_log." suffix=".log"
> > pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
> > %r %s %b"
> > requestAttributesEnabled="true" />
>
> That isn't correct. You only need to add
> requestAttributesEnabled="true"
> to the default AccessLogValve. It will handle looking up the correct
> attributes. You don't need to modify the pattern.
I already worked with a modified log layout before the change. I only
changed the %{org.apache.catalina.AccessLog.RemoteAddr}r. So would I
have to replace %{org.apache.catalina.AccessLog.RemoteAddr}r with a %a?
>
> I also confirmed that the Valve order doesn't matter.
So not like many on the Internet claim it matters?
>
> > The request header 'X-Forwarded-For'
> > was set and load balancer was analyzed via wireshark and Request
> > Dumper
> > Filter. We can see the header in both. However we still only get
> > the IP
> > of the load balancer and not the IP of the remote client. The IP
> > adresses of the config have already been checked and they are
> > correct.
>
> You can add "... %{X-Forwarded-For}i ..." to the pattern attribute of
> the AccessLog valve to confirm that Tomcat sees this header value.
In the beginning we tested it with Wireshark, later with a
RequestDumper in the Tomcat. In both we saw the header.
>
> I've tested this locally with the latest 7.0.x and everything works
> as
> expected. I also don't recall any changes / bugs in this area
> recently.
>
> A quick scan of the changelog does identify various improvements and
> fixes since 7.0.76 but none that immediately jump out as likely to
> cause
> this simple configuration to fail.
Thanks for looking into it.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7 does not log x-forwarded-for
Good morning all,
the answers are [inline].
With kind regards
Frank
Am Dienstag, den 31.03.2020, 10:08 -0400 schrieb Christopher Schultz:
> Frank,
>
> On 3/31/20 02:26, Frank Tornack wrote:
> > I currently have a problem with Tomcat7, or rather a colleague has
> > it.
>
> Which exact version of Tomcat 7?
It is version: 7.0.76
>
> > Personally I would like to help him, but I can't find the error
> > myself. We already asked the question on stackoverflow.com and got
> > a good hint, but unfortunately no solving. So I would like to ask
> > for help and support here. I think I am violating the directive of
> > asking a double question, but it is important to me personally to
> > help this colleague. Therefore I am at least honest, the question
> > can also be found at the link:
> > https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-do
> esnt-work-with-load-balancer
> > We run a software that uses Tomcat as application server behind a
> > load balancer. Now we would like to record the initial address of
> > the requests and not the IP of the load balancer. We have used
> > these 3 websites for the setup, but unfortunately it does not work.
> > The IPs of the loadbalancers are still written to the access log.
> > https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valve
> s/RemoteIpValve.html
> >
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/
> AccessLogValve.html
> > https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_V
> alve
>
> You
> are at least on the right track.
Thank you. I had the hope not to run completely in the wrong direction.
>
> > We used the following configuration for access logging and remote
> > valve: > internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xxx\.9
> > "
> > r emoteIpHeader="X-Forwarded-For" /> > className="org.apache.catalina.valves.AccessLogValve"
> > directory="logs" prefix="access_log." suffix=".log"
> > pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
> > %r %s %b" requestAttributesEnabled="true" />
>
> What is the IP address of your load-balancer(s)? One of those
> xxx.xxx.xxx.[789]?
the used load balancer uses three network cards in the Tomcat network.
We have not yet set up a grouping of the network cards, so all IPs are
listed here and linked with "or".
>
> > The request header 'X-Forwarded-For' was set and load balancer was
> > analyzed via wireshark and Request Dumper Filter. We can see the
> > header in both. However we still only get the IP of the load
> > balancer and not the IP of the remote client. The IP adresses of
> > the config have already been checked and they are correct.
> >
> > Thank you very much in advance for your support.
>
> Please post the that you are using to receive requests
> from your load-balancer.
>
> Are you seeing any warnings/errors in your log file when Tomcat
> starts? During the first few requests?
There are some errors, but as far as I know only application errors and
none from Tomcat itself.
>
> -chris
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
On 2020-03-31 15:34, Mark Thomas wrote: > On 31/03/2020 13:49, Aditya Kumar wrote: >> Hi Mark, >> >> Sorry I'm not familiar with what a Selector is? However on one system I've >> noticed 28000 such connections. Are these caused by client connections? I'm >> not saying the connection originates from a client, but does the type of >> socket get create because of client connections? > > A selector is what a NIO Connector uses to "select" the socket > connections that have data waiting to be processed out of all of the > current connections. I'd expect a 1:1 mapping between Selectors and > Tomcat Connectors. (It might be 2:1 to n+1:n I'd need to look at the > code to be sure but it will be driven by listening sockets on Tomcat, > not client connections. > > It looks like something is creating selectors but not destroying them. > That might be Tomcat code but at those numbers I think the application > is more likely. > > I recommend using a profiler to track the current number of Selectors > and trying to work out what triggers the creation of a new one. > > Mark > > >> >> On Tue, Mar 31, 2020 at 1:20 PM Mark Thomas wrote: >> >>> On 31/03/2020 11:20, Aditya Kumar wrote: Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 I've noticed on a freshly installed version of tomcat 9, upon startup >>> there are several connections to and from localhost on different ports For example on my tomcat server there are 4 connections to and from localhost (output from netstat) TCP0.0.0.0:8080 0.0.0.0:0 LISTENING >>> 3972 TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED >>> 3972 TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED >>> 3972 TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED >>> 3972 TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED >>> 3972 TCP[::]:8080 [::]:0 LISTENING >>> 3972 These can grow to a large number (several thousand) on a busy system. >>> What are these connections used for? What caused them? What thread are they attributed to? >>> >>> The Java NIO implementation on Windows uses TCP for intra-process >>> signalling. It opens a pair of self-connected sockets for every Selector. >>> >>> Mark Dear Aditya, dear all, it's also an effect from using "modern" Java stream I/O. You might notice (by consulting /proc/$N/fd/) even pipe handles in addition to the socket handles. The worse thing I discovered that they are not necessarily released by a minor garbage collection (after the corresponding java "instrument" is out-of-scope) but may be even remain until a full gc is running! And if you're using the up-to-date G1 GC, then -- as an explicit aim of design -- this will run very seldom. For my Tomcat (and Wildfly) instances of our "Java Application platform" I was forced to increase the (container) file descriptor limit a lot and in addition to write a watchdog which will fire an forced full GC on the JVM (via 'jcmd $PID GC.run') in case the number of fd is approaching the limit. This is because the Java heap is independed to the OS file descriptor resources and might not be become collected in the right time because the corresponding memory occupation of the related objects on the Java heap is typical right small. greetings Guido - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to increase Memory available to Tomcat?
Hi, I think I figured out what is going on. I think that the parameters were working all right, but the memory that is shown by the "free" command isn't corresponding to the JVM memory. I put together a small JSP that uses Runtime.getRuntime().totalMemory() and .freeMemory() and and when I access that page, that shows the JVM memory is as I configured with the Xmx/Xms. Thanks, Jim On Tue, Mar 31, 2020 at 10:03 PM o haya wrote: > Hi, > > BTW, in the catalina.out log file, I do see these lines: > > 01-Apr-2020 01:53:17.775 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Dfile.encoding=UTF-8 > 01-Apr-2020 01:53:17.775 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Xms4096m > 01-Apr-2020 01:53:17.775 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -Xmx4096m > 01-Apr-2020 01:53:17.775 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -XX:NewSize=256m > 01-Apr-2020 01:53:17.775 INFO [main] > org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: -XX:MaxNewSize=256m > > So from that logging, it seems like Tomcat IS seeing those parameters, so > why does it not seem to be using the larger amounts of memory? > > Thanks, > Jim > > > On Tue, Mar 31, 2020 at 9:44 PM o haya wrote: > >> Hi, >> >> I have Tomcat installed in /apps/apache-tomcat-9.0.20/ >> >> In the /apps/apache-tomcat-9.0.20/bin/setenv.sh, I have: >> >> #!/bin/bash >> >> JAVA_HOME=/apps/jdk1.8.0_221 >> >> CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ >> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m >> -XX:+DisableExplicitGC \ >> -Djava.security.egd=file:/dev/./urandom" >> >> >> Then to start Tomcat, I: >> >> cd /apps/apache-tomcat-9.0.20/ >> >> bin/startup.sh >> >> >> >> Here's an example of running: >> >> [root@ip-192-168-218-224 apache-tomcat-9.0.20]# free >> totalusedfree shared buff/cache >> available >> Mem: 32780604 91301227429012 16716 4438580 >> 31441736 >> Swap: 0 0 0 >> [root@ip-192-168-218-224 apache-tomcat-9.0.20]# cd >> /apps/apache-tomcat-9.0.20/ >> [root@ip-192-168-218-224 apache-tomcat-9.0.20]# >> [root@ip-192-168-218-224 apache-tomcat-9.0.20]# bin/startup.sh >> Using CATALINA_BASE: /apps/apache-tomcat-9.0.20 >> Using CATALINA_HOME: /apps/apache-tomcat-9.0.20 >> Using CATALINA_TMPDIR: /apps/apache-tomcat-9.0.20/temp >> Using JRE_HOME:/apps/jdk1.8.0_221 >> Using CLASSPATH: >> /apps/apache-tomcat-9.0.20/bin/bootstrap.jar:/apps/apache-tomcat-9.0.20/bin/tomcat-juli.jar >> Tomcat started. >> [root@ip-192-168-218-224 apache-tomcat-9.0.20]# free >> totalusedfree shared buff/cache >> available >> Mem: 32780604 134328826998784 16716 4438532 >> 31011556 >> >> >> >> You are right that it appears like it is not using the CATALINA_OPTS to >> set the memory, but I don't know why ??? >> >> >> Thanks, >> Jim >> >> >> >> >> >> On Tue, Mar 31, 2020 at 12:52 PM Mark Thomas wrote: >> >>> On 31/03/2020 17:42, o haya wrote: >>> > Thanks for the infos. >>> > >>> > I was thinking the same thing you were thinking, that it might be >>> 32-bit >>> > JVM, but when I run "java -version" I am getting: >>> > >>> > java -version >>> > java version "1.8.0_221" >>> > Java(TM) SE Runtime Environment (build 1.8.0_221-b11) >>> > Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode) >>> > >>> > Isn't that confirming that this is a 64-bit JVM? >>> > >>> > ALSO FYI, I did test where I also added "-d64" parameter to the >>> > CATALINA_OPTS, and same thing happened. >>> >>> Exactly how are you setting those? It looks like the changes you are >>> making aren't having any effect. If you specified a 4Gb min heap on a >>> 32-bit JVM I'd expect Java to either refuse to start or crash on start. >>> >>> Mark >>> >>> >>> > >>> > Jim >>> > >>> > On Tue, Mar 31, 2020 at 11:10 AM Olaf Kock wrote: >>> > >>> >> >>> >> On 31.03.20 17:02, o haya wrote: >>> >>> Hi, >>> >>> >>> >>> I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I >>> would >>> >>> like to increase the memory that is available to Tomcat when it is >>> >> running. >>> >>> >>> >>> I have tried sourcing the following: >>> >>> >>> >>> JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ >>> >>> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m >>> >>> -XX:+DisableExplicitGC \ >>> >>> -Djava.security.egd=file:/dev/./urandom -d64" >>> >> >>> >> You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS. >>> >> >>> >> JAVA_OPTS are used for every JVM start, including when you run >>> >> shutdown.sh - that one needs only a minimal amount of memory for short >>> >> time. >>> >> >>> >>> and also: >>> >>> >>> >>> CATALINA_OPTS="-Djava.awt.headless=true
Re: How to increase Memory available to Tomcat?
Hi, BTW, in the catalina.out log file, I do see these lines: 01-Apr-2020 01:53:17.775 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dfile.encoding=UTF-8 01-Apr-2020 01:53:17.775 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms4096m 01-Apr-2020 01:53:17.775 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx4096m 01-Apr-2020 01:53:17.775 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:NewSize=256m 01-Apr-2020 01:53:17.775 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:MaxNewSize=256m So from that logging, it seems like Tomcat IS seeing those parameters, so why does it not seem to be using the larger amounts of memory? Thanks, Jim On Tue, Mar 31, 2020 at 9:44 PM o haya wrote: > Hi, > > I have Tomcat installed in /apps/apache-tomcat-9.0.20/ > > In the /apps/apache-tomcat-9.0.20/bin/setenv.sh, I have: > > #!/bin/bash > > JAVA_HOME=/apps/jdk1.8.0_221 > > CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ > -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m > -XX:+DisableExplicitGC \ > -Djava.security.egd=file:/dev/./urandom" > > > Then to start Tomcat, I: > > cd /apps/apache-tomcat-9.0.20/ > > bin/startup.sh > > > > Here's an example of running: > > [root@ip-192-168-218-224 apache-tomcat-9.0.20]# free > totalusedfree shared buff/cache > available > Mem: 32780604 91301227429012 16716 4438580 > 31441736 > Swap: 0 0 0 > [root@ip-192-168-218-224 apache-tomcat-9.0.20]# cd > /apps/apache-tomcat-9.0.20/ > [root@ip-192-168-218-224 apache-tomcat-9.0.20]# > [root@ip-192-168-218-224 apache-tomcat-9.0.20]# bin/startup.sh > Using CATALINA_BASE: /apps/apache-tomcat-9.0.20 > Using CATALINA_HOME: /apps/apache-tomcat-9.0.20 > Using CATALINA_TMPDIR: /apps/apache-tomcat-9.0.20/temp > Using JRE_HOME:/apps/jdk1.8.0_221 > Using CLASSPATH: > /apps/apache-tomcat-9.0.20/bin/bootstrap.jar:/apps/apache-tomcat-9.0.20/bin/tomcat-juli.jar > Tomcat started. > [root@ip-192-168-218-224 apache-tomcat-9.0.20]# free > totalusedfree shared buff/cache > available > Mem: 32780604 134328826998784 16716 4438532 > 31011556 > > > > You are right that it appears like it is not using the CATALINA_OPTS to > set the memory, but I don't know why ??? > > > Thanks, > Jim > > > > > > On Tue, Mar 31, 2020 at 12:52 PM Mark Thomas wrote: > >> On 31/03/2020 17:42, o haya wrote: >> > Thanks for the infos. >> > >> > I was thinking the same thing you were thinking, that it might be 32-bit >> > JVM, but when I run "java -version" I am getting: >> > >> > java -version >> > java version "1.8.0_221" >> > Java(TM) SE Runtime Environment (build 1.8.0_221-b11) >> > Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode) >> > >> > Isn't that confirming that this is a 64-bit JVM? >> > >> > ALSO FYI, I did test where I also added "-d64" parameter to the >> > CATALINA_OPTS, and same thing happened. >> >> Exactly how are you setting those? It looks like the changes you are >> making aren't having any effect. If you specified a 4Gb min heap on a >> 32-bit JVM I'd expect Java to either refuse to start or crash on start. >> >> Mark >> >> >> > >> > Jim >> > >> > On Tue, Mar 31, 2020 at 11:10 AM Olaf Kock wrote: >> > >> >> >> >> On 31.03.20 17:02, o haya wrote: >> >>> Hi, >> >>> >> >>> I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I >> would >> >>> like to increase the memory that is available to Tomcat when it is >> >> running. >> >>> >> >>> I have tried sourcing the following: >> >>> >> >>> JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ >> >>> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m >> >>> -XX:+DisableExplicitGC \ >> >>> -Djava.security.egd=file:/dev/./urandom -d64" >> >> >> >> You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS. >> >> >> >> JAVA_OPTS are used for every JVM start, including when you run >> >> shutdown.sh - that one needs only a minimal amount of memory for short >> >> time. >> >> >> >>> and also: >> >>> >> >>> CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server >> \ >> >>> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m >> >>> -XX:+DisableExplicitGC \ >> >>> -Djava.security.egd=file:/dev/./urandom" >> >> >> >> your CATALINA_OPTS will be combined with the JAVA_OPTS, so that you >> >> configure the memory twice. >> >> >> >> But -Xms and -Xmx are the way to configure the memory. >> >> >> >>> but even with those, when I check memory using "free", it is only >> using >> >>> about 1.5GB. >> >>> >> >>> Can someone tell me how I can accomplish this? >> >> >> >> Sounds suspiciously like you're running on 32bit, either the OS or JVM. >> >> Upgrade to
Re: How to increase Memory available to Tomcat?
Hi, I have Tomcat installed in /apps/apache-tomcat-9.0.20/ In the /apps/apache-tomcat-9.0.20/bin/setenv.sh, I have: #!/bin/bash JAVA_HOME=/apps/jdk1.8.0_221 CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:+DisableExplicitGC \ -Djava.security.egd=file:/dev/./urandom" Then to start Tomcat, I: cd /apps/apache-tomcat-9.0.20/ bin/startup.sh Here's an example of running: [root@ip-192-168-218-224 apache-tomcat-9.0.20]# free totalusedfree shared buff/cache available Mem: 32780604 91301227429012 16716 4438580 31441736 Swap: 0 0 0 [root@ip-192-168-218-224 apache-tomcat-9.0.20]# cd /apps/apache-tomcat-9.0.20/ [root@ip-192-168-218-224 apache-tomcat-9.0.20]# [root@ip-192-168-218-224 apache-tomcat-9.0.20]# bin/startup.sh Using CATALINA_BASE: /apps/apache-tomcat-9.0.20 Using CATALINA_HOME: /apps/apache-tomcat-9.0.20 Using CATALINA_TMPDIR: /apps/apache-tomcat-9.0.20/temp Using JRE_HOME:/apps/jdk1.8.0_221 Using CLASSPATH: /apps/apache-tomcat-9.0.20/bin/bootstrap.jar:/apps/apache-tomcat-9.0.20/bin/tomcat-juli.jar Tomcat started. [root@ip-192-168-218-224 apache-tomcat-9.0.20]# free totalusedfree shared buff/cache available Mem: 32780604 134328826998784 16716 4438532 31011556 You are right that it appears like it is not using the CATALINA_OPTS to set the memory, but I don't know why ??? Thanks, Jim On Tue, Mar 31, 2020 at 12:52 PM Mark Thomas wrote: > On 31/03/2020 17:42, o haya wrote: > > Thanks for the infos. > > > > I was thinking the same thing you were thinking, that it might be 32-bit > > JVM, but when I run "java -version" I am getting: > > > > java -version > > java version "1.8.0_221" > > Java(TM) SE Runtime Environment (build 1.8.0_221-b11) > > Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode) > > > > Isn't that confirming that this is a 64-bit JVM? > > > > ALSO FYI, I did test where I also added "-d64" parameter to the > > CATALINA_OPTS, and same thing happened. > > Exactly how are you setting those? It looks like the changes you are > making aren't having any effect. If you specified a 4Gb min heap on a > 32-bit JVM I'd expect Java to either refuse to start or crash on start. > > Mark > > > > > > Jim > > > > On Tue, Mar 31, 2020 at 11:10 AM Olaf Kock wrote: > > > >> > >> On 31.03.20 17:02, o haya wrote: > >>> Hi, > >>> > >>> I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I > would > >>> like to increase the memory that is available to Tomcat when it is > >> running. > >>> > >>> I have tried sourcing the following: > >>> > >>> JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ > >>> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m > >>> -XX:+DisableExplicitGC \ > >>> -Djava.security.egd=file:/dev/./urandom -d64" > >> > >> You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS. > >> > >> JAVA_OPTS are used for every JVM start, including when you run > >> shutdown.sh - that one needs only a minimal amount of memory for short > >> time. > >> > >>> and also: > >>> > >>> CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ > >>> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m > >>> -XX:+DisableExplicitGC \ > >>> -Djava.security.egd=file:/dev/./urandom" > >> > >> your CATALINA_OPTS will be combined with the JAVA_OPTS, so that you > >> configure the memory twice. > >> > >> But -Xms and -Xmx are the way to configure the memory. > >> > >>> but even with those, when I check memory using "free", it is only using > >>> about 1.5GB. > >>> > >>> Can someone tell me how I can accomplish this? > >> > >> Sounds suspiciously like you're running on 32bit, either the OS or JVM. > >> Upgrade to 64bit to have access to more memory. > >> > >> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Increase Transfer-Encoding limit in Apache Tomcat 9.0.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Suraj, On 3/31/20 13:44, Agrawal, Suraj (CORP) wrote: > Thanks for your response, yes the source application is not able > to handle "Chunked" response so we want to disable it or at least > increase the size. 臘♂️ This is a required part of HTTP 1.1 which was released in 1996. Your client is 25 years old? Is your client requesting an HTTP 1.1 response? If so, it should NOT do that because it cannot handle one. It should instead request an HTTP 1.0 response instead, at which point Tomcat will not generate a chunked response. Instead, it will allow a streaming response and close the connection after the response has completed. Better yet, if you can modify the client, FIX IT to it can actually handle chunked responses. > We recently ,moved from IIS to apache tomcat as default webserver > for application. > > Also, I tried adding below in server.xml in HTTP/1.1 section but > that did not helped. > > - maxTrailerSize="-1" - maxExtensionSize="-1" None of those things will affect returning a chunked response. Mostly your application can trigger chunked responses. Tomcat only returns a chunked response if your application fills the output buffer without setting a Content-Length header. Check your code. Are you setting a Content-Length header? If not, then you need to either expand the output buffer to ensure your response fits into it or compute your Content-Length before filling that output buffer. - -chris > -Original Message- From: Mark Thomas > Sent: Tuesday, March 31, 2020 12:51 PM To: users@tomcat.apache.org > Subject: Re: Increase Transfer-Encoding limit in Apache Tomcat > 9.0.14 > > > WARNING: Do not click links or open attachments unless you > recognize the source of the email and know the contents are safe. > > ** > > On 31/03/2020 17:35, Agrawal, Suraj (CORP) wrote: >> >> Hi Team, >> >> We are getting webserver response failure when the response >> message is large then 20 kb, I was reading and looks like Apache >> Tomcat set "Transfer-Encoding = Chunked" when the size of message >> increases 8 kb by default. > > You haven't demonstrated that those two statements are cause and > effect. > > Please describe the failure in detail. > > Tomcat will quite happily serve responses that are multiple Gb in > size so I'd be surprised if this turned out to be a Tomcat issue. > > Are you saying that the client you are using can't handled a > chunked response? > >> Can you please help how we can disable "Transfer-Encoding = >> Chunked" or increase its size in Apache Tomcat 9.0.14 (we are >> using Windows Server). I also tried adding below in server.xml >> but that did not help; > > Adding what, exactly? The entire Connector? An attribute? Something > to an attribute? > > Mark > > >> >> >
RE: Increase Transfer-Encoding limit in Apache Tomcat 9.0.14
Hi Mark, Thanks for your response, yes the source application is not able to handle "Chunked" response so we want to disable it or at least increase the size. We recently ,moved from IIS to apache tomcat as default webserver for application. Also, I tried adding below in server.xml in HTTP/1.1 section but that did not helped. - maxTrailerSize="-1" - maxExtensionSize="-1" Thanks & Regards, Suraj Agrawal -Original Message- From: Mark Thomas Sent: Tuesday, March 31, 2020 12:51 PM To: users@tomcat.apache.org Subject: Re: Increase Transfer-Encoding limit in Apache Tomcat 9.0.14 WARNING: Do not click links or open attachments unless you recognize the source of the email and know the contents are safe. ** On 31/03/2020 17:35, Agrawal, Suraj (CORP) wrote: > > Hi Team, > > We are getting webserver response failure when the response message is large > then 20 kb, I was reading and looks like Apache Tomcat set "Transfer-Encoding > = Chunked" when the size of message increases 8 kb by default. You haven't demonstrated that those two statements are cause and effect. Please describe the failure in detail. Tomcat will quite happily serve responses that are multiple Gb in size so I'd be surprised if this turned out to be a Tomcat issue. Are you saying that the client you are using can't handled a chunked response? > Can you please help how we can disable "Transfer-Encoding = Chunked" > or increase its size in Apache Tomcat 9.0.14 (we are using Windows > Server). I also tried adding below in server.xml but that did not > help; Adding what, exactly? The entire Connector? An attribute? Something to an attribute? Mark > > relaxedQueryChars="" > > relaxedPathChars="" > compressableMimeType="text/html,text/xml,text/css,text/javascript, > application/x-javascript,application/javascript" > compression="on" > compressionMinSize="128" > connectionTimeout="200" > noCompressionUserAgents="gozilla, traviata" > maxpostsize="-1" > maxHttpHeaderSize="65536" > maxTrailerSize="-1" > maxExtensionSize="-1" > redirectPort="9011" /> > > Many thanks for your help in advance. > > Thanks & Regards, > Suraj Agrawal > > -- > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, notify the sender immediately by return > email and delete the message and any attachments from your system. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9.31 PUT/POST Request receiving Partial Data
Hi,
On Tue, Mar 31, 2020 at 8:17 PM
wrote:
> -Original Message-
> > From: Bhavesh Mistry
> > Sent: Wednesday, February 26, 2020 7:51 PM
> > To: Tomcat Users List
> > Subject: Re: Tomcat 9.31 PUT/POST Request receiving Partial Data
>
> > The response get truncated after 16321 bytes. Please let me know what
> is best way to wait and in > order to consume entire request payload.
>
> > Thanks,
> > Bhavesh
>
> > On Wed, Feb 26, 2020 at 4:34 PM Bhavesh Mistry <
> mistry.p.bhav...@gmail.com>
> > wrote:
>
> > Hi Tomcat Team,
> >
> > I have servlet filter for all requests to cache the entire PUT/POST
> > Payload. When content is large 4KB or more, I am getting partial
> content
> > when I read from HttpServletRequest.getInputStream(). But I but 10
> > seconds wait before consuming the input stream, I am getting entire
> > content. Can you please let me know what is the correct way to wait
> > for the entire content is ready to consume from the tomcat servlet
> request input stream?
> >
> >
> > Filter Code:
> > If I put Thread.sleep(10) at begin of filter, I am getting full
> > content.
> >
> > @Override
> > protected void doFilterInternal(HttpServletRequest httpServletRequest,
> HttpServletResponse httpServletResponse, FilterChain filterChain) throws
> ServletException, IOException {
> > CachedBodyHttpServletRequest cachedBodyHttpServletRequest = new
> CachedBodyHttpServletRequest(httpServletRequest);
> > filterChain.doFilter(cachedBodyHttpServletRequest,
> > httpServletResponse); }
> >
> > // Wrapper to cache content.
> >
> > public CachedBodyHttpServletRequest(HttpServletRequest request) throws
> IOException {
> > super(request);
> > ServletInputStream inputStream = request.getInputStream();
> > final int len = request.getContentLength();
> > if (len >= 0) {
> > cachedBody = new byte[len];
> > ByteStreams.readFully(inputStream, cachedBody);
> > } else {
> > cachedBody = ByteStreams.toByteArray(inputStream);
> > }
> > }
> >
> >
> > Thanks,
> >
> > Bhavesh
> >
>
> I have a team reporting the same issue with 9.0.31. Reverting to 9.0.30
> resolves their issue. Here are some details:
>
> STEPS done to identify cause :-
> 1. We have tried to increase maxSwallowSize , connectionTimeout ,
> socket.appWriteBufSize="24576" on tomcat 9.0.31 but issue still persisted
> 2. We tried to roll back java upgrade from 1.8.0.242 to 1.8.0.231 but
> issue still persisted
> 3. Enabled SSL debug log to verify if request gets dropped at but it
> was not very helpful .
> 4. FINALLY when we rolledback tomcat upgrade to 9.0.30 , same request
> worked fine .
>
> We were basically getting 400 error for few requests while smaller request
> always succeeds while larger request (100kb-180kb) frequently gets dropped
> or partially processed.
> Now we are using the 9.0.30 version until its resolved from tomcat side .
>
Have you tried 9.0.33 ?
I believe this is fixed in .33.
Martin
Re: Tomcat Connection Rest Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gary, On 3/31/20 13:20, Hua, Gary - Saint Louis, MO - Contractor wrote: > After we deploy our application to production in Tomcat server > 9.0.33, we got following error when multiple users login for some > time and the server hangs. Where does the server hang? On logins? Do you have a thread dump of a "hung" server? > When user click the "Login" button on the login form, it has a > security realm that connect to the LDAP as in the server.xml: > > connectionURL="ldaps://" /> > > > 30-Mar-2020 12:47:29.218 INFO [https-jsse-nio-9443-exec-30] > org.apache.catalina.realm.JNDIRealm.authenticate Exception > performing authentication. Retrying... > > javax.naming.CommunicationException: Connection reset [Root > exception is java.net.SocketException: Connection reset]; remaining > name "XXX" > > at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2002) [snip] > > Caused by: java.net.SocketException: Connection reset > > at java.net.SocketInputStream.read(SocketInputStream.java:210) > [snip] This often happens because a firewall terminates a long-lived connection. When encountering an error like this, Tomcat should retry its connection and work-around any such termination. You can see that this is an INFO message and not an ERROR. Does Tomcat eventually log anything suggesting that there is a successful connection? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6DfaUACgkQHPApP6U8 pFgWcg/7BufYygaJeerkpwGuCXafQ9f/xTFTPevvgfL2PSD9/iZiYm7vOTWXqwrP 7xn8XRUEmycNROq31pfFyfDP8IJqlrRwampEoRRzVbQDXwBdeNDHlFILL7+BVrvP 0q9Wgb9WdWlPuVv/ZYMM5GLRVxhoCX68p0tRlmxpOM/U4Uiaa9eDR809GCliNWa9 +QThei2UewGfOsIQovpSU76qUuSnmcIf2iy6UJ2DkKH7mLmbyX58WW3JAX4Y1kPY CV1jUVQ58KRcqD3bgHrEarMkAWI6AhgrXFf6MaqC8z0NPykPmeiwfAl4JY3kkUsU LmxzJqfQoztv+NJdcsBwjV+hA81zeeAP/6NfV/q1kTocHYYea5wKSJXRFFbGUeh/ STAu2pw5yA43tZvW9Nthn2SJS1lC7XMs/izi95J+srxjxedMg3i/NfkBiaf78i42 GXnjxNIi8GBPTQZ4hEL83p8Jn1r0jd/13zCUSAcpiV8svTBlWhqPelVXti4fuL41 ssqpAmhe4A0lUDnnpiGZHld57oA5K3FJ46c6PRhjR5hu9/nQig3d3cZuqFlimnwK 79PeLquSewFTNDOVbJhhYsQzPgMOFNejo50E88AVQWIWMDqAtEzFZ87LFlLjq3cI Hek1jV4PMpDjnaJNERJdzRMSAhXdyu5JIjkia3+s/d8B8Q+htR4= =c9iM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Connection Rest Error
Experts: After we deploy our application to production in Tomcat server 9.0.33, we got following error when multiple users login for some time and the server hangs. When user click the "Login" button on the login form, it has a security realm that connect to the LDAP as in the server.xml: _realm; cat LDAP_realm.xml 30-Mar-2020 12:47:29.218 INFO [https-jsse-nio-9443-exec-30] org.apache.catalina.realm.JNDIRealm.authenticate Exception performing authentication. Retrying... javax.naming.CommunicationException: Connection reset [Root exception is java.net.SocketException: Connection reset]; remaining name "XXX" at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2002) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1844) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1685) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1521) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1469) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1414) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1296) at org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:190) at org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:154) at org.apache.catalina.authenticator.FormAuthenticator.doAuthenticate(FormAuthenticator.java:243) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:631) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:688) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210) at java.net.SocketInputStream.read(SocketInputStream.java:141) at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) at sun.security.ssl.InputRecord.read(InputRecord.java:503) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975) at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:933) at sun.security.ssl.AppInputStream.read(AppInputStream.java:105) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at
RE: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31
Please ignore this. Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 – 12/31 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: jonmcalexan...@wellsfargo.com.INVALID Sent: Tuesday, March 31, 2020 12:07 PM To: users@tomcat.apache.org Subject: RE: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 Tomcat 9.0.33 is available in the SAML Software Library and in HPSA. I would recommend downloading that and seeing if that corrects the issue. Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 – 12/31 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Mark Thomas Sent: Tuesday, March 17, 2020 1:06 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 On 17/03/2020 17:56, Amit Pande wrote: > Using Tomcat 9.0.31. > > When using large JSON payload (little less than 2 MB) for POST requests, randomly (all random failures seen are on Windows and not on *ix), we are seeing: > > JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz ["str"]) - JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz["str"])at > > For smaller payloads, no issues are observed. > > Will this also be addressed by upgrading to 9.0.32/33? Maybe. The only way for you to be sure that the issue you describe is the same as Bug 64202 is for you to download 9.0.33 and test it in your test environment. Mark > > Thanks, > Amit > > -Original Message- > From: Manuel Dominguez Sarmiento > Sent: Tuesday, March 17, 2020 10:52 AM > To: Tomcat Users List ; Christopher Schultz > Subject: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 > > Great, I just saw that :-) > > On 17/03/2020 11:24, Christopher Schultz wrote: > 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 if we haven't run into this particular case directly (yet) > 9.0.33 was announced about 20 minutes ago :) > > -chris > 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 Kochunni wrote: >> Hi All, >> >> >> >> This is to seek help on a strange issue that we are observing. >> We recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, >> in our application, in order to address vulnerability in AJP >> connector. Ever since then we have started seeing upload failures >> with our upload servlet when processing large files. >> Small files do get uploaded, but when we upload large files and >> we do Multipart file upload, we are randomly and yet consistently >> seeing that we get the following exception. >> >> >> >> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: >> >> > Processing of multipart/form-data request failed. Stream ended >> unexpectedly >> >> at >> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpl >> oa >> d > Base.java:351) >> >> >> > >> Caused by:
RE: Tomcat 9.31 PUT/POST Request receiving Partial Data
-Original Message-
> From: Bhavesh Mistry
> Sent: Wednesday, February 26, 2020 7:51 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 9.31 PUT/POST Request receiving Partial Data
> The response get truncated after 16321 bytes. Please let me know what is
> best way to wait and in > order to consume entire request payload.
> Thanks,
> Bhavesh
> On Wed, Feb 26, 2020 at 4:34 PM Bhavesh Mistry
> wrote:
> Hi Tomcat Team,
>
> I have servlet filter for all requests to cache the entire PUT/POST
> Payload. When content is large 4KB or more, I am getting partial content
> when I read from HttpServletRequest.getInputStream(). But I but 10
> seconds wait before consuming the input stream, I am getting entire
> content. Can you please let me know what is the correct way to wait
> for the entire content is ready to consume from the tomcat servlet request
> input stream?
>
>
> Filter Code:
> If I put Thread.sleep(10) at begin of filter, I am getting full
> content.
>
> @Override
> protected void doFilterInternal(HttpServletRequest httpServletRequest,
> HttpServletResponse httpServletResponse, FilterChain filterChain) throws
> ServletException, IOException {
> CachedBodyHttpServletRequest cachedBodyHttpServletRequest = new
> CachedBodyHttpServletRequest(httpServletRequest);
> filterChain.doFilter(cachedBodyHttpServletRequest,
> httpServletResponse); }
>
> // Wrapper to cache content.
>
> public CachedBodyHttpServletRequest(HttpServletRequest request) throws
> IOException {
> super(request);
> ServletInputStream inputStream = request.getInputStream();
> final int len = request.getContentLength();
> if (len >= 0) {
> cachedBody = new byte[len];
> ByteStreams.readFully(inputStream, cachedBody);
> } else {
> cachedBody = ByteStreams.toByteArray(inputStream);
> }
> }
>
>
> Thanks,
>
> Bhavesh
>
I have a team reporting the same issue with 9.0.31. Reverting to 9.0.30
resolves their issue. Here are some details:
STEPS done to identify cause :-
1. We have tried to increase maxSwallowSize , connectionTimeout ,
socket.appWriteBufSize="24576" on tomcat 9.0.31 but issue still persisted
2. We tried to roll back java upgrade from 1.8.0.242 to 1.8.0.231 but
issue still persisted
3. Enabled SSL debug log to verify if request gets dropped at but it was
not very helpful .
4. FINALLY when we rolledback tomcat upgrade to 9.0.30 , same request
worked fine .
We were basically getting 400 error for few requests while smaller request
always succeeds while larger request (100kb-180kb) frequently gets dropped or
partially processed.
Now we are using the 9.0.30 version until its resolved from tomcat side .
Re: Why does Tomcat open connections on localhost?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
John,
On 3/31/20 10:37, John Dale wrote:
> I always appreciate your depth of knowledge, Chris.
>
> "hand-wavy device supporting NIO for Java"
>
> Could you write us a quick paragraph expanding on this idea?
>
> I'm happy to follow a pointer to a well written article (something
> up to your standards).
I mostly called it "hand-wavy" because I do not understand it myself:
it's indistinguishable from magic from my perspective. At least at the
kernel-level.
Mark or others may be able to intervene and tell me I'm wrong, but it
seems like Java's NIO ("new IO") is nothing new: the standard C
library from 1970 contains the select() function which is exactly what
a Selector does. It takes a whole bunch of I/O channels and waits for
one of them to have activity, returning the set of channels with
activity that the caller can then handle.
Imagine writing "telnet" in Java with only java.io.InputStream and
java.io.OutputStream. First, you'd connect to the telnet server and
probably wait for some input like a password challenge, using
InputStream.read() for some reasonable time. But how do you know when
the "password prompt" is done? Maybe there is more input.
InputStream.read has a read-timeout, but it will block until there's
data or EOF (or timeout). There's no signalling that can be done from
server to client or vice versa.
Let's forget about login. What about sitting at command-line? Do you
sit there blocking on the InputStream listening for client input (e.g.
keyboard) or the InputStream from the server waiting for server input
(e.g. "System going down for maintenance in 10:00!")?
You just can't do it.
So with a Selector, you grab the channels for all those things (e.g.
keyboard, server), and say "hey, selector, I don't care whose ready
next, but let me know when something interesting happens". The
selector waits for EITHER the keyboard OR the server to provide input,
and then the thread waiting on the selector wakes up and gets the
message: "keyboard has data" and you handle it (probably by sending
that data to the server)". Or maybe it was "server has data" and you
print it to the screen. The point is that, with a Selector, you can
actually implement something like telnet where with, uh, "old IO" you
could not practically implement it.
This takes us back to the magic: for some reason, OS kernels need to
create a structure to use for the selector under the covers. [I did my
TCP/IP university work long ago, and don't ever remember discussing or
even noticing any domain socket being set up when a select() was being
called, but that may just be because it wasn't important to us at that
point -- an implementation detail.] Windows versus Linux choose to do
those things in different ways with different manifestations. Why do
they need it? Why did they choose those specific manifestations? I
have no idea. Go ask Ken Thompson or Dennis Richie (RIP). Or
serverfault. The information is out there. I can't give you a
canonical source myself.
If someone wants to provide a good reference, I'd love to read it myself
.
- -chris
> On 3/31/20, Christopher Schultz
> wrote: Frank,
>
> On 3/31/20 09:30, Frank Tornack wrote:
Yes, these too are for communication between processes. Only
you don't use the network stack. This is a special feature of
Unix-like operating systems.
DGRAM, unlike STREAM, does not know connection states.
Therefore STREAM is comparable to a local TCP connection.
Unix domain sockets exist in the file tree as special files.
Access is controlled by file permissions, as is usual for
files.
>
> Yup. It's helpful to see the column headers for your netstat
> output, André:
>
Proto RefCnt Flags Type State I-Node
PID/Program name Path unix 2 [ ] STREAM
CONNECTED 167427210 27514/java unix 2 [ ]
STREAM CONNECTED 167423436 27514/java
>
> Each "unix" protocol-connection (UNIX domain socket) has an
> associated inode on the root filesystem, but no path. Basically,
> it's magic. :)
>
> The nice thing on *NIX is that even though there is a hand-wavy
> device supporting NIO for Java, it doesn't consume pairs of ports
> (which are a limited resource; see our recent discussion on the
> limits of TCP port numbers).
>
> -chris
>
Am Dienstag, den 31.03.2020, 14:29 +0200 schrieb André
Warnier (tomcat/perl):
> On 31.03.2020 14:20, Mark Thomas wrote:
>> On 31/03/2020 11:20, Aditya Kumar wrote:
>>> Tomcat 9.0.30 on Windows Server 2012 / Java 1.8
>>>
>>> I've noticed on a freshly installed version of tomcat
>>> 9, upon startup there are several connections to and
>>> from localhost on different ports
>>>
>>> For example on my tomcat server there are 4 connections
>>> to and from localhost (output from netstat)
>>>
>>>
>>> TCP0.0.0.0:8080 0.0.0.0:0 LISTENING 3972
>>>
>>> TCP
RE: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31
Tomcat 9.0.33 is available in the SAML Software Library and in HPSA. I would recommend downloading that and seeing if that corrects the issue. Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 – 12/31 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Mark Thomas Sent: Tuesday, March 17, 2020 1:06 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 On 17/03/2020 17:56, Amit Pande wrote: > Using Tomcat 9.0.31. > > When using large JSON payload (little less than 2 MB) for POST requests, randomly (all random failures seen are on Windows and not on *ix), we are seeing: > > JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz ["str"]) - JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz["str"])at > > For smaller payloads, no issues are observed. > > Will this also be addressed by upgrading to 9.0.32/33? Maybe. The only way for you to be sure that the issue you describe is the same as Bug 64202 is for you to download 9.0.33 and test it in your test environment. Mark > > Thanks, > Amit > > -Original Message- > From: Manuel Dominguez Sarmiento > Sent: Tuesday, March 17, 2020 10:52 AM > To: Tomcat Users List ; Christopher Schultz > Subject: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 > > Great, I just saw that :-) > > On 17/03/2020 11:24, Christopher Schultz wrote: > 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 if we haven't run into this particular case directly (yet) > 9.0.33 was announced about 20 minutes ago :) > > -chris > 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 Kochunni wrote: >> Hi All, >> >> >> >> This is to seek help on a strange issue that we are observing. >> We recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, >> in our application, in order to address vulnerability in AJP >> connector. Ever since then we have started seeing upload failures >> with our upload servlet when processing large files. >> Small files do get uploaded, but when we upload large files and >> we do Multipart file upload, we are randomly and yet consistently >> seeing that we get the following exception. >> >> >> >> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: >> >> > Processing of multipart/form-data request failed. Stream ended >> unexpectedly >> >> at >> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpl >> oa >> d > Base.java:351) >> >> >> > >> Caused by: >> org.apache.commons.fileupload.MultipartStream$MalformedStreamExce >> pt >> i > on: >> > Stream ended unexpectedly >> at >> org.apache.commons.fileupload.MultipartStream$ItemInputStream.mak >> eA >> v > ailable(MultipartStream.java:1005) >> >> >> > at >> org.apache.commons.fileupload.MultipartStream$ItemInputStream.rea >> d( >> M > ultipartStream.java:903) >> >> >> > at java.io.InputStream.read(InputStream.java:101) >> at >> org.apache.commons.fileupload.util.Streams.copy(Streams.java:100) >> >> >> > at >> org.apache.commons.fileupload.util.Streams.copy(Streams.java:70) >> >> >> > at >> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpl >> oa >> d > Base.java:347) >> >> >> >> >> > It appears that the connection is getting reset in the >> middle of the upload, but the client is very much up and we get >> PR_CONNECT_RESET_ERROR on the browser. >> >> >>
Re: How to increase Memory available to Tomcat?
On 31/03/2020 17:42, o haya wrote: > Thanks for the infos. > > I was thinking the same thing you were thinking, that it might be 32-bit > JVM, but when I run "java -version" I am getting: > > java -version > java version "1.8.0_221" > Java(TM) SE Runtime Environment (build 1.8.0_221-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode) > > Isn't that confirming that this is a 64-bit JVM? > > ALSO FYI, I did test where I also added "-d64" parameter to the > CATALINA_OPTS, and same thing happened. Exactly how are you setting those? It looks like the changes you are making aren't having any effect. If you specified a 4Gb min heap on a 32-bit JVM I'd expect Java to either refuse to start or crash on start. Mark > > Jim > > On Tue, Mar 31, 2020 at 11:10 AM Olaf Kock wrote: > >> >> On 31.03.20 17:02, o haya wrote: >>> Hi, >>> >>> I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I would >>> like to increase the memory that is available to Tomcat when it is >> running. >>> >>> I have tried sourcing the following: >>> >>> JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ >>> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m >>> -XX:+DisableExplicitGC \ >>> -Djava.security.egd=file:/dev/./urandom -d64" >> >> You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS. >> >> JAVA_OPTS are used for every JVM start, including when you run >> shutdown.sh - that one needs only a minimal amount of memory for short >> time. >> >>> and also: >>> >>> CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ >>> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m >>> -XX:+DisableExplicitGC \ >>> -Djava.security.egd=file:/dev/./urandom" >> >> your CATALINA_OPTS will be combined with the JAVA_OPTS, so that you >> configure the memory twice. >> >> But -Xms and -Xmx are the way to configure the memory. >> >>> but even with those, when I check memory using "free", it is only using >>> about 1.5GB. >>> >>> Can someone tell me how I can accomplish this? >> >> Sounds suspiciously like you're running on 32bit, either the OS or JVM. >> Upgrade to 64bit to have access to more memory. >> >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Increase Transfer-Encoding limit in Apache Tomcat 9.0.14
On 31/03/2020 17:35, Agrawal, Suraj (CORP) wrote: > > Hi Team, > > We are getting webserver response failure when the response message is large > then 20 kb, I was reading and looks like Apache Tomcat set "Transfer-Encoding > = Chunked" when the size of message increases 8 kb by default. You haven't demonstrated that those two statements are cause and effect. Please describe the failure in detail. Tomcat will quite happily serve responses that are multiple Gb in size so I'd be surprised if this turned out to be a Tomcat issue. Are you saying that the client you are using can't handled a chunked response? > Can you please help how we can disable "Transfer-Encoding = Chunked" or > increase its size in Apache Tomcat 9.0.14 (we are using Windows Server). I > also tried adding below in server.xml but that did not help; Adding what, exactly? The entire Connector? An attribute? Something to an attribute? Mark > > relaxedQueryChars="" > > relaxedPathChars="" > compressableMimeType="text/html,text/xml,text/css,text/javascript, > application/x-javascript,application/javascript" > compression="on" > compressionMinSize="128" > connectionTimeout="200" > noCompressionUserAgents="gozilla, traviata" > maxpostsize="-1" > maxHttpHeaderSize="65536" > maxTrailerSize="-1" > maxExtensionSize="-1" > redirectPort="9011" /> > > Many thanks for your help in advance. > > Thanks & Regards, > Suraj Agrawal > > -- > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, notify the sender immediately by return > email and delete the message and any attachments from your system. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to increase Memory available to Tomcat?
Thanks for the infos. I was thinking the same thing you were thinking, that it might be 32-bit JVM, but when I run "java -version" I am getting: java -version java version "1.8.0_221" Java(TM) SE Runtime Environment (build 1.8.0_221-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode) Isn't that confirming that this is a 64-bit JVM? ALSO FYI, I did test where I also added "-d64" parameter to the CATALINA_OPTS, and same thing happened. Jim On Tue, Mar 31, 2020 at 11:10 AM Olaf Kock wrote: > > On 31.03.20 17:02, o haya wrote: > > Hi, > > > > I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I would > > like to increase the memory that is available to Tomcat when it is > running. > > > > I have tried sourcing the following: > > > > JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ > > -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m > > -XX:+DisableExplicitGC \ > > -Djava.security.egd=file:/dev/./urandom -d64" > > You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS. > > JAVA_OPTS are used for every JVM start, including when you run > shutdown.sh - that one needs only a minimal amount of memory for short > time. > > > and also: > > > > CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ > > -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m > > -XX:+DisableExplicitGC \ > > -Djava.security.egd=file:/dev/./urandom" > > your CATALINA_OPTS will be combined with the JAVA_OPTS, so that you > configure the memory twice. > > But -Xms and -Xmx are the way to configure the memory. > > > but even with those, when I check memory using "free", it is only using > > about 1.5GB. > > > > Can someone tell me how I can accomplish this? > > Sounds suspiciously like you're running on 32bit, either the OS or JVM. > Upgrade to 64bit to have access to more memory. > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Increase Transfer-Encoding limit in Apache Tomcat 9.0.14
Hi Team, We are getting webserver response failure when the response message is large then 20 kb, I was reading and looks like Apache Tomcat set "Transfer-Encoding = Chunked" when the size of message increases 8 kb by default. Can you please help how we can disable "Transfer-Encoding = Chunked" or increase its size in Apache Tomcat 9.0.14 (we are using Windows Server). I also tried adding below in server.xml but that did not help; Many thanks for your help in advance. Thanks & Regards, Suraj Agrawal -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
Re: How to increase Memory available to Tomcat?
On 31.03.20 17:02, o haya wrote: > Hi, > > I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I would > like to increase the memory that is available to Tomcat when it is running. > > I have tried sourcing the following: > > JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ > -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m > -XX:+DisableExplicitGC \ > -Djava.security.egd=file:/dev/./urandom -d64" You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS. JAVA_OPTS are used for every JVM start, including when you run shutdown.sh - that one needs only a minimal amount of memory for short time. > and also: > > CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ > -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m > -XX:+DisableExplicitGC \ > -Djava.security.egd=file:/dev/./urandom" your CATALINA_OPTS will be combined with the JAVA_OPTS, so that you configure the memory twice. But -Xms and -Xmx are the way to configure the memory. > but even with those, when I check memory using "free", it is only using > about 1.5GB. > > Can someone tell me how I can accomplish this? Sounds suspiciously like you're running on 32bit, either the OS or JVM. Upgrade to 64bit to have access to more memory. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cookie configurations for Tomcat 7
Chris, Did you managed to check the PR? Lazar On Tue, Mar 10, 2020 at 5:41 PM Lazar Kirchev wrote: > Chris, > > Any update on this? Did you have a chance to have a look on the PR? > > Lazar > > On Wed, Mar 4, 2020 at 10:55 AM Lazar Kirchev > wrote: > >> Chris, Martin, >> >> Here is the PR: https://github.com/apache/tomcat/pull/252 >> >> Lazar >> >> On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov >> wrote: >> >>> On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev >>> wrote: >>> >>> > Chris, >>> > >>> > I just thought that I have some concerns passing a map with the >>> headers to >>> > generateCookie() method. This means that for each call the caller will >>> have >>> > to read all headers from the coyote.Response and put them in a map, >>> even if >>> > the CookieProcessor will not need them, as is the case with the legacy >>> > cookie processor and the rfc cookie processor. This might have >>> performance >>> > impact. Isn't it more optimal to just pass the o.a.c.connector.Request >>> - >>> > like generateCookie (Request, Cookie) - and then if the cookie >>> processor >>> > implementation needs headers, it will take them - only these which it >>> needs >>> > - from the Response. >>> > What do you think? >>> > >>> >>> I agree that this is a better way! >>> >>> Martin >>> >>> >>> > >>> > Lazar >>> > >>> > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev >>> wrote: >>> > >>> > > >>> > > Chris, >>> > > >>> > > Actually in my preferred option the implementation in the >>> > > CookieProcessorBase should not be no-op, but it should call >>> > > CookieProcessor.generateCookie(Cookie). And the calls to >>> > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response >>> and >>> > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to >>> the >>> > new >>> > > method. >>> > > >>> > > Lazar >>> > > >>> > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev < >>> lazar.kirc...@gmail.com> >>> > > wrote: >>> > > >>> > >> Chris, >>> > >> >>> > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 >>> should >>> > >> be able to work both on Java 7 and Java 8, interface default methods >>> > can't >>> > >> be used. So would you prefer to have a second >>> > CookieProcessor.generateCookie(Map<> >>> > >> requestHeaders, Cookie) in addition to the existing >>> > CookieProcessor.generateCookie(Cookie), >>> > >> and provide a no-op implementation in the CookieProcessorBase >>> class, or >>> > to >>> > >> change the signature of the existing method instead? I myself >>> prefer the >>> > >> first option, with adding a second method. >>> > >> >>> > >> Lazar >>> > >> >>> > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < >>> > >> ch...@christopherschultz.net> wrote: >>> > >> >>> > >>> -BEGIN PGP SIGNED MESSAGE- >>> > >>> Hash: SHA256 >>> > >>> >>> > >>> Lazar, >>> > >>> >>> > >>> On 2/24/20 02:05, Lazar Kirchev wrote: >>> > >>> > Chris, >>> > >>> > >>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will >>> > >>> > work perfectly for me and I guess for anyone who needs to check >>> the >>> > >>> > client version. >>> > >>> >>> > >>> Want to prepare a PR? >>> > >>> >>> > >>> - -chris >>> > >>> >>> > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < >>> > >>> > ch...@christopherschultz.net> wrote: >>> > >>> > >>> > >>> > Lazar, >>> > >>> > >>> > >>> > On 2/21/20 10:29, Lazar Kirchev wrote: >>> > >>> Yes, the SameSite attribute is still in a draft and this >>> > >>> causes the mess, at least partly.> And yes, I was thinking >>> > >>> about something like that - >>> > >>> CookieProcessor.generateCookie(String userAgent, Cookie) or >>> > >>> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). >>> > >>> I >>> > >>> > absolutely >>> > >>> agree that this would be very hacky. And it might be >>> > >>> dangerous as CookieProcessor is an interface and there >>> > >>> already might be custom implementations. >>> > >>> > >>> > >>> > We can fix that with default implementations, for Java versions >>> > >>> > that support such thing (Java >= 1.8). >>> > >>> > >>> > >>> But can you think of another way of making the cookie >>> > >>> generation logic aware of the user agent header value? >>> > >>> > >>> > >>> > Not really. >>> > >>> > >>> > >>> > I have a preference for: >>> > >>> > >>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) >>> > >>> > >>> > >>> > This is because User-Agent might not be the only header which is >>> > >>> > useful, here. For example, Google Chrome (amusingly enough) will >>> > >>> > be removing the User-Agent header[1] in favor of "client >>> > >>> > hints"[2]. >>> > >>> > >>> > >>> > So you might have to look at more than one header at a time, >>> > >>> > including possibly User-Agent. >>> > >>> > >>> > >>> > -chris >>> > >>> > >>> > >>> > [1] >>> > >>> > >>> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i >>> > >>> n- >>> > >>> >
How to increase Memory available to Tomcat?
Hi, I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I would like to increase the memory that is available to Tomcat when it is running. I have tried sourcing the following: JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:+DisableExplicitGC \ -Djava.security.egd=file:/dev/./urandom -d64" and also: CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \ -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:+DisableExplicitGC \ -Djava.security.egd=file:/dev/./urandom" but even with those, when I check memory using "free", it is only using about 1.5GB. Can someone tell me how I can accomplish this? Thanks, Jim
Re: tomcat7 does not log x-forwarded-for
On 31/03/2020 07:26, Frank Tornack wrote:
> Hello all,
>
> I currently have a problem with Tomcat7, or rather a colleague has it.
> Personally I would like to help him, but I can't find the error myself.
> We already asked the question on stackoverflow.com and got a good hint,
> but unfortunately no solving. So I would like to ask for help and
> support here. I think I am violating the directive of asking a double
> question, but it is important to me personally to help this colleague.
> Therefore I am at least honest, the question can also be found at the
> link:
> https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-doesnt-work-with-load-balancer
Which at least enables us to find the one key piece of information
missing in this question, the version of Tomcat being used: 7.0.76
> We run a software that uses Tomcat as application server behind a load
> balancer. Now we would like to record the initial address of the
> requests and not the IP of the load balancer. We have used these 3
> websites for the setup, but unfortunately it does not work. The IPs of
> the loadbalancers are still written to the access log.
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/AccessLogValve.html
> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve
>
> We used the following configuration for access logging and remote
> valve:
> internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xxx\.9" r
> emoteIpHeader="X-Forwarded-For" />
The remoteIpHeader setting is unnecessary. That is the default.
> directory="logs"
> prefix="access_log." suffix=".log"
> pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
> %r %s %b"
> requestAttributesEnabled="true" />
That isn't correct. You only need to add requestAttributesEnabled="true"
to the default AccessLogValve. It will handle looking up the correct
attributes. You don't need to modify the pattern.
I also confirmed that the Valve order doesn't matter.
> The request header 'X-Forwarded-For'
> was set and load balancer was analyzed via wireshark and Request Dumper
> Filter. We can see the header in both. However we still only get the IP
> of the load balancer and not the IP of the remote client. The IP
> adresses of the config have already been checked and they are correct.
You can add "... %{X-Forwarded-For}i ..." to the pattern attribute of
the AccessLog valve to confirm that Tomcat sees this header value.
I've tested this locally with the latest 7.0.x and everything works as
expected. I also don't recall any changes / bugs in this area recently.
A quick scan of the changelog does identify various improvements and
fixes since 7.0.76 but none that immediately jump out as likely to cause
this simple configuration to fail.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
I always appreciate your depth of knowledge, Chris. "hand-wavy device supporting NIO for Java" Could you write us a quick paragraph expanding on this idea? I'm happy to follow a pointer to a well written article (something up to your standards). On 3/31/20, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Frank, > > On 3/31/20 09:30, Frank Tornack wrote: >> Yes, these too are for communication between processes. Only you >> don't use the network stack. This is a special feature of Unix-like >> operating systems. >> >> DGRAM, unlike STREAM, does not know connection states. Therefore >> STREAM is comparable to a local TCP connection. Unix domain sockets >> exist in the file tree as special files. Access is controlled by >> file permissions, as is usual for files. > > Yup. It's helpful to see the column headers for your netstat output, > André: > >> Proto RefCnt Flags Type State I-Node >> PID/Program name Path unix 2 [ ] STREAM >> CONNECTED 167427210 27514/java unix 2 [ ] STREAM >> CONNECTED 167423436 27514/java > > Each "unix" protocol-connection (UNIX domain socket) has an associated > inode on the root filesystem, but no path. Basically, it's magic. :) > > The nice thing on *NIX is that even though there is a hand-wavy device > supporting NIO for Java, it doesn't consume pairs of ports (which are > a limited resource; see our recent discussion on the limits of TCP > port numbers). > > - -chris > >> Am Dienstag, den 31.03.2020, 14:29 +0200 schrieb André Warnier >> (tomcat/perl): >>> On 31.03.2020 14:20, Mark Thomas wrote: On 31/03/2020 11:20, Aditya Kumar wrote: > Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 > > I've noticed on a freshly installed version of tomcat 9, > upon startup there are several connections to and from > localhost on different ports > > For example on my tomcat server there are 4 connections to > and from localhost (output from netstat) > > > TCP0.0.0.0:8080 0.0.0.0:0 > LISTENING 3972 > > TCP127.0.0.1:55618127.0.0.1:55619 > ESTABLISHED 3972 > > TCP127.0.0.1:55619127.0.0.1:55618 > ESTABLISHED 3972 > > TCP127.0.0.1:55620127.0.0.1:55621 > ESTABLISHED 3972 > > TCP127.0.0.1:55621127.0.0.1:55620 > ESTABLISHED 3972 > > TCP[::]:8080 [::]:0 > LISTENING 3972 > > These can grow to a large number (several thousand) on a > busy system. What are these connections used for? What caused > them? What thread are they attributed to? The Java NIO implementation on Windows uses TCP for intra-process signalling. It opens a pair of self-connected sockets for every Selector. Mark >>> >>> While we're at it, under Linux, are the following for a similar >>> reason ? >>> >>> output of : netstat -pan | grep 27514 (tomcat's JVM PID = >>> 27514) [...] unix 2 [ ] STREAM CONNECTED >>> 167427210 27514/java unix 2 [ ] STREAM >>> CONNECTED 167423436 27514/java >>> >>> >>> >>> - >>> >>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> - >> >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6DUP8ACgkQHPApP6U8 > pFgxiBAAkmLWWhwvrLW+RJ5j3ZKEu5cXQ0x3/zsMpFuP2GPok1lemXixa8T91lSO > eGg6W80DhVb76tDJl4Akt3L8ejN2XNgSxnHgGfEiCvTughYryAmHNXxze3ZMj4BQ > pvIO8hCc1nSlti71h6C2vEGYLnwkHyMulIolYaHP+SxKX7PSxXcfo4zD6vvpTvnO > U5Hrk7H8JjXCANrd8LsChN8w8AkWMUJpu/TUXFYy8bWEN9Ui7SdGqfa1t+pwnl8+ > JZqO1moBP9WcMA/XR1msWIbkA8B1r+ICWqlqcdGlvkXrHzkiALdqpxy0WiKAs1Tn > J+uPp0mAGpXRU3NGibr5NMtHLQ3Kl+X821yHYjF0XjqFwjLgvQNrmdYwblqFCUPB > 9sIVr6CuWAxPM61QZ9Bi9fT4MrIA6f8iSEa7BDJmUWhARPQMKn6fjIOMd8Cok882 > cGU1WT8O2SrtQV+y7wJbbq4aP4e6vRi/nSqI2hlSFdTBfD1Grj+t5JPHg35AafR4 > +6qum9rVF3AKf47UoJFrXG9smWLkUVVsJuZbdHLofmQEV0ovOMzAPx2GR9oSR2/M > sCxdUdqrhEW08wwYwIOV59vNa9pn/X/SOEre09yLH/GMV3H03CiQni616luWPrQt > 0BzFi4+8TPVzKCaq88ThyjJnEMuDU9RNeS7IHScHTXQa6rflB7E= > =q/Fd > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
On 31.03.2020 15:30, Mark Thomas wrote: On 31/03/2020 13:29, André Warnier (tomcat/perl) wrote: On 31.03.2020 14:20, Mark Thomas wrote: On 31/03/2020 11:20, Aditya Kumar wrote: Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 I've noticed on a freshly installed version of tomcat 9, upon startup there are several connections to and from localhost on different ports For example on my tomcat server there are 4 connections to and from localhost (output from netstat) TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 3972 TCP 127.0.0.1:55618 127.0.0.1:55619 ESTABLISHED 3972 TCP 127.0.0.1:55619 127.0.0.1:55618 ESTABLISHED 3972 TCP 127.0.0.1:55620 127.0.0.1:55621 ESTABLISHED 3972 TCP 127.0.0.1:55621 127.0.0.1:55620 ESTABLISHED 3972 TCP [::]:8080 [::]:0 LISTENING 3972 These can grow to a large number (several thousand) on a busy system. What are these connections used for? What caused them? What thread are they attributed to? The Java NIO implementation on Windows uses TCP for intra-process signalling. It opens a pair of self-connected sockets for every Selector. Mark While we're at it, under Linux, are the following for a similar reason ? output of : netstat -pan | grep 27514 (tomcat's JVM PID = 27514) [...] unix 2 [ ] STREAM CONNECTED 167427210 27514/java unix 2 [ ] STREAM CONNECTED 167423436 27514/java Don't know. One possible way to check would be to add an additional NIO connector and see if you get more of them. Note : this is not very important, was just curiosity But Nope. I added a second HTTP Connector (port 8180), which by default should be NIO : and restarted tomcat, but the number of listed unix sockets remains the same : root@xxx:~# netstat -pan | grep 32647 (tomcat 8.5 has a new PID) tcp6 0 0 127.0.0.1:8005 :::*LISTEN 32647/java tcp6 0 0 127.0.0.1:8009 :::*LISTEN 32647/java tcp6 0 0 :::8080 :::*LISTEN 32647/java tcp6 0 0 127.0.0.1:8180 :::*LISTEN 32647/java tcp6 0 0 127.0.0.1:8009 127.0.0.1:45190 ESTABLISHED 32647/java unix 2 [ ] STREAM CONNECTED 190838270 32647/java unix 2 [ ] STREAM CONNECTED 190846897 32647/java root@darwin:~# - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Frank, On 3/31/20 09:30, Frank Tornack wrote: > Yes, these too are for communication between processes. Only you > don't use the network stack. This is a special feature of Unix-like > operating systems. > > DGRAM, unlike STREAM, does not know connection states. Therefore > STREAM is comparable to a local TCP connection. Unix domain sockets > exist in the file tree as special files. Access is controlled by > file permissions, as is usual for files. Yup. It's helpful to see the column headers for your netstat output, André: > Proto RefCnt Flags Type State I-Node > PID/Program name Path unix 2 [ ] STREAM > CONNECTED 167427210 27514/java unix 2 [ ] STREAM > CONNECTED 167423436 27514/java Each "unix" protocol-connection (UNIX domain socket) has an associated inode on the root filesystem, but no path. Basically, it's magic. :) The nice thing on *NIX is that even though there is a hand-wavy device supporting NIO for Java, it doesn't consume pairs of ports (which are a limited resource; see our recent discussion on the limits of TCP port numbers). - -chris > Am Dienstag, den 31.03.2020, 14:29 +0200 schrieb André Warnier > (tomcat/perl): >> On 31.03.2020 14:20, Mark Thomas wrote: >>> On 31/03/2020 11:20, Aditya Kumar wrote: Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 I've noticed on a freshly installed version of tomcat 9, upon startup there are several connections to and from localhost on different ports For example on my tomcat server there are 4 connections to and from localhost (output from netstat) TCP0.0.0.0:8080 0.0.0.0:0 LISTENING 3972 TCP127.0.0.1:55618127.0.0.1:55619 ESTABLISHED 3972 TCP127.0.0.1:55619127.0.0.1:55618 ESTABLISHED 3972 TCP127.0.0.1:55620127.0.0.1:55621 ESTABLISHED 3972 TCP127.0.0.1:55621127.0.0.1:55620 ESTABLISHED 3972 TCP[::]:8080 [::]:0 LISTENING 3972 These can grow to a large number (several thousand) on a busy system. What are these connections used for? What caused them? What thread are they attributed to? >>> >>> The Java NIO implementation on Windows uses TCP for >>> intra-process signalling. It opens a pair of self-connected >>> sockets for every Selector. >>> >>> Mark >>> >> >> While we're at it, under Linux, are the following for a similar >> reason ? >> >> output of : netstat -pan | grep 27514 (tomcat's JVM PID = >> 27514) [...] unix 2 [ ] STREAM CONNECTED >> 167427210 27514/java unix 2 [ ] STREAM >> CONNECTED 167423436 27514/java >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6DUP8ACgkQHPApP6U8 pFgxiBAAkmLWWhwvrLW+RJ5j3ZKEu5cXQ0x3/zsMpFuP2GPok1lemXixa8T91lSO eGg6W80DhVb76tDJl4Akt3L8ejN2XNgSxnHgGfEiCvTughYryAmHNXxze3ZMj4BQ pvIO8hCc1nSlti71h6C2vEGYLnwkHyMulIolYaHP+SxKX7PSxXcfo4zD6vvpTvnO U5Hrk7H8JjXCANrd8LsChN8w8AkWMUJpu/TUXFYy8bWEN9Ui7SdGqfa1t+pwnl8+ JZqO1moBP9WcMA/XR1msWIbkA8B1r+ICWqlqcdGlvkXrHzkiALdqpxy0WiKAs1Tn J+uPp0mAGpXRU3NGibr5NMtHLQ3Kl+X821yHYjF0XjqFwjLgvQNrmdYwblqFCUPB 9sIVr6CuWAxPM61QZ9Bi9fT4MrIA6f8iSEa7BDJmUWhARPQMKn6fjIOMd8Cok882 cGU1WT8O2SrtQV+y7wJbbq4aP4e6vRi/nSqI2hlSFdTBfD1Grj+t5JPHg35AafR4 +6qum9rVF3AKf47UoJFrXG9smWLkUVVsJuZbdHLofmQEV0ovOMzAPx2GR9oSR2/M sCxdUdqrhEW08wwYwIOV59vNa9pn/X/SOEre09yLH/GMV3H03CiQni616luWPrQt 0BzFi4+8TPVzKCaq88ThyjJnEMuDU9RNeS7IHScHTXQa6rflB7E= =q/Fd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: R: R: Support with error in launcher.log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Luigi, On 3/31/20 04:50, Luigi Tagliafierro wrote: > Hi everybody, > > the question is, where is usually set the domain name? i've > checked all the HTTPD conf and it is correctly set without the "." in front of the domain. I've checked also the conf of the applications (confluence,jira ecc) and in the proxy name is set correctly. > > Also, how can we try to simply remove this cookie? Nobody here will be able to tell where your application is setting this cookie. It's probably not happening in httpd. Try using "grep" on your Java source tree, looking for "new Cookie". - -chris > Da: Christopher Schultz Inviato: > lunedì 30 marzo 2020 17:55 A: users@tomcat.apache.org > Oggetto: Re: R: Support with error in > launcher.log > > Luigi, > > On 3/30/20 08:38, Luigi Tagliafierro wrote: >> we have already tried to implement the legacy cookie processor >> but with no result. > > What did you actually do? What was the actual result? > > I suspect that because: > > 1. The cookie domain is invalid 2. This error has been present "for > a long time" 3. Nobody seems to have noticed > > This means that your cookie has never been working and nobody > cares about it. Perhaps whatever is using this cookie can simply be > removed from your application? > > -chris > >> Da: calder >> Inviato: lunedì 30 marzo 2020 13:14 A: >> Tomcat Users List Cc: Alessio Torelli >> Oggetto: Re: Support with error in >> launcher.log > >> On Mon, Mar 30, 2020, 05:02 Luigi Tagliafierro >> wrote: > >>> Hi everybody, >>> >>> we are experiencing an error : The bitbucket log >>> (/var/atlassian/bitbucket_home/log/launcher.log) constantly >>> repeats this error: >>> >>> "java.lang.IllegalArgumentException: An invalid domain >>> > > >> [.code.doxee.com] was specified for this cookie" . >>> > >> Issue: the domain has a dot (.) at its beginning. > > >> The error has been present in the log for some time and >> continues to be. >>> >>> We contacted the support of atlassian, who after an analysis >>> suggested that we ask you about the error in question. Here >>> the link to the discussion, *and all the info, tests and steps >>> we took before contacting you* : >>> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP- 4 > >>> 2041 >>> >>> >>> > Our Tomcat version is: 8.5.29 >>> >>> In attachment there is the complete error. >>> >>> We are waiting for an answer that can help you analyze or >>> solve the problem, >>> >>> Thanks a lot, Regards, >>> >>> Luigi >>> > >>> > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6DT0kACgkQHPApP6U8 pFjVOg/9HUfgqBfDdzg7v0UebsY1+fbhJX5GuMqzpWDbK42EJPfs/89tfP4ue1eT dOoe6X7zryhrEEh95/apI0kPuTceICjWkV5TAr0vbju8El8QW0lix+NBEp3T8NlI CHorV7z3Af+Kg9Nw1vKbRHrphE3/FZrzdJekqK2s//EVIfqaq6dSJ3RR2bUxpdGZ sH6QydWZ4ZxAGEBUuDVAQSDYLMFJYpoz3vfnyV9YJnQgQi7jicB3P8QzBzuo7w+n HPs+HO3pgtyqv0Axx0ZJIf2LxHO16nBGdlM5EAE7u5wbY5VW7JQhuKGhIgqMABvc qaCvrOilr0V962yzjqLEjI4fzizxsoA0XD07XsukCplX1mXUlElhUpjjqdpd2gW4 VfuHEgntbPoe+UFOLaUYVLv6vJMTMptVc5UQGGokFjK/5QLIweKp+xmfu0/61F15 CEZsdSm3cmzj8bmEDQ9RPWUI70JZfBhTCnn5h6jZSfCgkrKJKFEASw2DxSP63SkU GqG/Xe3a4iG8odZ61eirMx1P5tMbE2oANn7s64vy0/PwK9IM+LMIfaSTq6Zzk2YX NbcalLkug81uIjMRx8wFsZRk5KQGub6sSZGNguOrs9vKAFq7/9q7bdtuvsTWHNOy CtPGyl7VPpYsONAHcbL5U1vi3ZzfqyqoO12a7KHUOV3hrAKOV3Y= =WT8a -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7 does not log x-forwarded-for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Frank,
On 3/31/20 02:26, Frank Tornack wrote:
> I currently have a problem with Tomcat7, or rather a colleague has
> it.
Which exact version of Tomcat 7?
> Personally I would like to help him, but I can't find the error
> myself. We already asked the question on stackoverflow.com and got
> a good hint, but unfortunately no solving. So I would like to ask
> for help and support here. I think I am violating the directive of
> asking a double question, but it is important to me personally to
> help this colleague. Therefore I am at least honest, the question
> can also be found at the link:
> https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-do
esnt-work-with-load-balancer
>
> We run a software that uses Tomcat as application server behind a
> load balancer. Now we would like to record the initial address of
> the requests and not the IP of the load balancer. We have used
> these 3 websites for the setup, but unfortunately it does not work.
> The IPs of the loadbalancers are still written to the access log.
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valve
s/RemoteIpValve.html
>
>
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/
AccessLogValve.html
> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_V
alve
You
>
are at least on the right track.
> We used the following configuration for access logging and remote
> valve: internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xxx\.9"
> r emoteIpHeader="X-Forwarded-For" /> className="org.apache.catalina.valves.AccessLogValve"
> directory="logs" prefix="access_log." suffix=".log"
> pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
> %r %s %b" requestAttributesEnabled="true" />
What is the IP address of your load-balancer(s)? One of those
xxx.xxx.xxx.[789]?
> The request header 'X-Forwarded-For' was set and load balancer was
> analyzed via wireshark and Request Dumper Filter. We can see the
> header in both. However we still only get the IP of the load
> balancer and not the IP of the remote client. The IP adresses of
> the config have already been checked and they are correct.
>
> Thank you very much in advance for your support.
Please post the that you are using to receive requests
from your load-balancer.
Are you seeing any warnings/errors in your log file when Tomcat
starts? During the first few requests?
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6DTvoACgkQHPApP6U8
pFhlDw//Xnes0kbjYIQjMHJTTUKJHqNg54YNr4iS+JbDPotzKWkYOXtuC1CoX5zV
RPHc3w7wzVQuqCWoRLJJ7AIFXFH1NPG8D1UfALCI/SpLRHgE7v6RZKRTgVqGCNCQ
zYkloRV8pKZfQfYTc9qiTZYse0EmUkAbg0vHx+vUduI04mOFEsEL/3K15e4ERrAq
HuMr2orHMepxFfkoRbE+uZmcSgyXec7XupLvrd0pUZRXT5futmgmqw0tmH0vMQM5
ZLMjW51LTvO+Ps5oR15Lfny55U6yxME7UkJa8QhsEEo8dSJV8eDiEiWo0uPEIIxr
LfSp8TpZ4vBprcZB1EkFvBQfFsHxfxQbuMLO9iGsAq+AHjolp6A95V+QDwN8Fpaf
ZxekTijUvzsb+CFNmq1t8LG3BPhmdtgGRODf4Zoq029DnVMdhHDPxjAMeBk6y4uV
bAQ6pQDbL6fozcjHPnf4xgfq0PtHk4ow7P3NiUl52SPvyBMCacGnenEME3bAUAFf
UZr9CV47DEszPzOxI1bvRZG8J6Epz8BIcPSKTlQF86F0AHEZEXmenLVRj6EdrZ2B
cH7D61Px3wLtjjR3Qd5xgJnuMkUOVc6xdvKFc+X9rHPc3hsBqHMtHGT0FwGaay/L
rQtwOzzNcVVUdIfrHUmIYOtBbsTUXoomP0uOV5ReBVHYBprIHBg=
=k6fr
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletRequest.getRemoteAddr() sometimes returns NULL on Tomcat 9.0.30 and HTTP/2 secure requests
On 31/03/2020 14:36, Manuel Dominguez Sarmiento wrote:
> 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
Correct.
Mark
>
> *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, Manuel Dominguez Sarmiento wrote:
> Do the streams with errors all share the same connection ID? I suspect
> an error on one stream is triggering the closure of the connection and
> what you are seeing is the fallout of closing the connection.
That makes sense and is kind of what we're suspecting. How can we check
the connection/stream id? Can this be logged by AccessLogValve?
>>> Not easily at the moment. That looks like something we should fix. I'll
>>> see what I can do for 9.0.34.
>> From 8.5.54, 9.0.34 and 10.0.0-M4 the following request attributes will
>> be available for HTTP/2
>>
>> org.apache.coyote.connectionID
>> org.apache.coyote.streamID
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletRequest.getRemoteAddr() sometimes returns NULL on Tomcat 9.0.30 and HTTP/2 secure requests
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, Manuel Dominguez Sarmiento wrote:
Do the streams with errors all share the same connection ID? I suspect
an error on one stream is triggering the closure of the connection and
what you are seeing is the fallout of closing the connection.
That makes sense and is kind of what we're suspecting. How can we check
the connection/stream id? Can this be logged by AccessLogValve?
Not easily at the moment. That looks like something we should fix. I'll
see what I can do for 9.0.34.
From 8.5.54, 9.0.34 and 10.0.0-M4 the following request attributes will
be available for HTTP/2
org.apache.coyote.connectionID
org.apache.coyote.streamID
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
On 31/03/2020 13:49, Aditya Kumar wrote: > Hi Mark, > > Sorry I'm not familiar with what a Selector is? However on one system I've > noticed 28000 such connections. Are these caused by client connections? I'm > not saying the connection originates from a client, but does the type of > socket get create because of client connections? A selector is what a NIO Connector uses to "select" the socket connections that have data waiting to be processed out of all of the current connections. I'd expect a 1:1 mapping between Selectors and Tomcat Connectors. (It might be 2:1 to n+1:n I'd need to look at the code to be sure but it will be driven by listening sockets on Tomcat, not client connections. It looks like something is creating selectors but not destroying them. That might be Tomcat code but at those numbers I think the application is more likely. I recommend using a profiler to track the current number of Selectors and trying to work out what triggers the creation of a new one. Mark > > On Tue, Mar 31, 2020 at 1:20 PM Mark Thomas wrote: > >> On 31/03/2020 11:20, Aditya Kumar wrote: >>> Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 >>> >>> I've noticed on a freshly installed version of tomcat 9, upon startup >> there >>> are several connections to and from localhost on different ports >>> >>> For example on my tomcat server there are 4 connections to and from >>> localhost (output from netstat) >>> >>> TCP0.0.0.0:8080 0.0.0.0:0 LISTENING >> 3972 >>> TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED >> 3972 >>> TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED >> 3972 >>> TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED >> 3972 >>> TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED >> 3972 >>> TCP[::]:8080 [::]:0 LISTENING >> 3972 >>> >>> These can grow to a large number (several thousand) on a busy system. >> What >>> are these connections used for? What caused them? What thread are they >>> attributed to? >> >> The Java NIO implementation on Windows uses TCP for intra-process >> signalling. It opens a pair of self-connected sockets for every Selector. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
Yes, these too are for communication between processes. Only you don't use the network stack. This is a special feature of Unix-like operating systems. DGRAM, unlike STREAM, does not know connection states. Therefore STREAM is comparable to a local TCP connection. Unix domain sockets exist in the file tree as special files. Access is controlled by file permissions, as is usual for files. Am Dienstag, den 31.03.2020, 14:29 +0200 schrieb André Warnier (tomcat/perl): > On 31.03.2020 14:20, Mark Thomas wrote: > > On 31/03/2020 11:20, Aditya Kumar wrote: > > > Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 > > > > > > I've noticed on a freshly installed version of tomcat 9, upon > > > startup there > > > are several connections to and from localhost on different ports > > > > > > For example on my tomcat server there are 4 connections to and > > > from > > > localhost (output from netstat) > > > > > > > > > TCP0.0.0.0:8080 0.0.0.0:0 LISTENING > > > 3972 > > > > > > TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED > > > 3972 > > > > > > TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED > > > 3972 > > > > > > TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED > > > 3972 > > > > > > TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED > > > 3972 > > > > > > TCP[::]:8080 [::]:0 LISTENING > > > 3972 > > > > > > These can grow to a large number (several thousand) on a busy > > > system. What > > > are these connections used for? What caused them? What thread are > > > they > > > attributed to? > > > > The Java NIO implementation on Windows uses TCP for intra-process > > signalling. It opens a pair of self-connected sockets for every > > Selector. > > > > Mark > > > > While we're at it, under Linux, are the following for a similar > reason ? > > output of : netstat -pan | grep 27514 (tomcat's JVM PID = 27514) > [...] > unix 2 [ ] STREAM CONNECTED 167427210 > 27514/java > unix 2 [ ] STREAM CONNECTED 167423436 > 27514/java > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
On 31/03/2020 13:29, André Warnier (tomcat/perl) wrote: > On 31.03.2020 14:20, Mark Thomas wrote: >> On 31/03/2020 11:20, Aditya Kumar wrote: >>> Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 >>> >>> I've noticed on a freshly installed version of tomcat 9, upon startup >>> there >>> are several connections to and from localhost on different ports >>> >>> For example on my tomcat server there are 4 connections to and from >>> localhost (output from netstat) >>> >>> TCP 0.0.0.0:8080 0.0.0.0:0 >>> LISTENING 3972 >>> TCP 127.0.0.1:55618 127.0.0.1:55619 >>> ESTABLISHED 3972 >>> TCP 127.0.0.1:55619 127.0.0.1:55618 >>> ESTABLISHED 3972 >>> TCP 127.0.0.1:55620 127.0.0.1:55621 >>> ESTABLISHED 3972 >>> TCP 127.0.0.1:55621 127.0.0.1:55620 >>> ESTABLISHED 3972 >>> TCP [::]:8080 [::]:0 >>> LISTENING 3972 >>> >>> These can grow to a large number (several thousand) on a busy system. >>> What >>> are these connections used for? What caused them? What thread are they >>> attributed to? >> >> The Java NIO implementation on Windows uses TCP for intra-process >> signalling. It opens a pair of self-connected sockets for every Selector. >> >> Mark >> > > While we're at it, under Linux, are the following for a similar reason ? > > output of : netstat -pan | grep 27514 (tomcat's JVM PID = 27514) > [...] > unix 2 [ ] STREAM CONNECTED 167427210 27514/java > unix 2 [ ] STREAM CONNECTED 167423436 27514/java Don't know. One possible way to check would be to add an additional NIO connector and see if you get more of them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletRequest.getRemoteAddr() sometimes returns NULL on Tomcat 9.0.30 and HTTP/2 secure requests
On 29/03/2020 16:16, Mark Thomas wrote: > On 29/03/2020 15:58, Manuel Dominguez Sarmiento wrote: >> >>> Do the streams with errors all share the same connection ID? I suspect >>> an error on one stream is triggering the closure of the connection and >>> what you are seeing is the fallout of closing the connection. >> That makes sense and is kind of what we're suspecting. How can we check >> the connection/stream id? Can this be logged by AccessLogValve? > > Not easily at the moment. That looks like something we should fix. I'll > see what I can do for 9.0.34. >From 8.5.54, 9.0.34 and 10.0.0-M4 the following request attributes will be available for HTTP/2 org.apache.coyote.connectionID org.apache.coyote.streamID Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
Hi Mark, Sorry I'm not familiar with what a Selector is? However on one system I've noticed 28000 such connections. Are these caused by client connections? I'm not saying the connection originates from a client, but does the type of socket get create because of client connections? On Tue, Mar 31, 2020 at 1:20 PM Mark Thomas wrote: > On 31/03/2020 11:20, Aditya Kumar wrote: > > Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 > > > > I've noticed on a freshly installed version of tomcat 9, upon startup > there > > are several connections to and from localhost on different ports > > > > For example on my tomcat server there are 4 connections to and from > > localhost (output from netstat) > > > > TCP0.0.0.0:8080 0.0.0.0:0 LISTENING > 3972 > > TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED > 3972 > > TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED > 3972 > > TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED > 3972 > > TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED > 3972 > > TCP[::]:8080 [::]:0 LISTENING > 3972 > > > > These can grow to a large number (several thousand) on a busy system. > What > > are these connections used for? What caused them? What thread are they > > attributed to? > > The Java NIO implementation on Windows uses TCP for intra-process > signalling. It opens a pair of self-connected sockets for every Selector. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Why does Tomcat open connections on localhost?
On 31.03.2020 14:20, Mark Thomas wrote: On 31/03/2020 11:20, Aditya Kumar wrote: Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 I've noticed on a freshly installed version of tomcat 9, upon startup there are several connections to and from localhost on different ports For example on my tomcat server there are 4 connections to and from localhost (output from netstat) TCP0.0.0.0:8080 0.0.0.0:0 LISTENING 3972 TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED 3972 TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED 3972 TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED 3972 TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED 3972 TCP[::]:8080 [::]:0 LISTENING 3972 These can grow to a large number (several thousand) on a busy system. What are these connections used for? What caused them? What thread are they attributed to? The Java NIO implementation on Windows uses TCP for intra-process signalling. It opens a pair of self-connected sockets for every Selector. Mark While we're at it, under Linux, are the following for a similar reason ? output of : netstat -pan | grep 27514 (tomcat's JVM PID = 27514) [...] unix 2 [ ] STREAM CONNECTED 167427210 27514/java unix 2 [ ] STREAM CONNECTED 167423436 27514/java - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
On 31/03/2020 11:20, Aditya Kumar wrote: > Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 > > I've noticed on a freshly installed version of tomcat 9, upon startup there > are several connections to and from localhost on different ports > > For example on my tomcat server there are 4 connections to and from > localhost (output from netstat) > > TCP0.0.0.0:8080 0.0.0.0:0 LISTENING 3972 > TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED 3972 > TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED 3972 > TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED 3972 > TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED 3972 > TCP[::]:8080 [::]:0 LISTENING 3972 > > These can grow to a large number (several thousand) on a busy system. What > are these connections used for? What caused them? What thread are they > attributed to? The Java NIO implementation on Windows uses TCP for intra-process signalling. It opens a pair of self-connected sockets for every Selector. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
Hi Aditya, I'm not quite sure, but it could be a replacement for the sockets that a Linux system provides for inter-process communication. But it's just a guess, because I don't see this behavior on Linux. kindly Frank Am Dienstag, den 31.03.2020, 11:20 +0100 schrieb Aditya Kumar: > Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 > > I've noticed on a freshly installed version of tomcat 9, upon startup > there > are several connections to and from localhost on different ports > > For example on my tomcat server there are 4 connections to and from > localhost (output from netstat) > > TCP0.0.0.0:8080 0.0.0.0:0 LISTENING > 3972 > TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED > 3972 > TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED > 3972 > TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED > 3972 > TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED > 3972 > TCP[::]:8080 [::]:0 LISTENING > 3972 > > These can grow to a large number (several thousand) on a busy system. > What > are these connections used for? What caused them? What thread are > they > attributed to? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Why does Tomcat open connections on localhost?
Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 I've noticed on a freshly installed version of tomcat 9, upon startup there are several connections to and from localhost on different ports For example on my tomcat server there are 4 connections to and from localhost (output from netstat) TCP0.0.0.0:8080 0.0.0.0:0 LISTENING 3972 TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED 3972 TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED 3972 TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED 3972 TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED 3972 TCP[::]:8080 [::]:0 LISTENING 3972 These can grow to a large number (several thousand) on a busy system. What are these connections used for? What caused them? What thread are they attributed to?
R: R: Support with error in launcher.log
Hi everybody, the question is, where is usually set the domain name? i've checked all the HTTPD conf and it is correctly set without the "." in front of the domain. I've checked also the conf of the applications (confluence,jira ecc) and in the proxy name is set correctly. Also, how can we try to simply remove this cookie? thanks, Luigi Da: Christopher Schultz Inviato: lunedì 30 marzo 2020 17:55 A: users@tomcat.apache.org Oggetto: Re: R: Support with error in launcher.log -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Luigi, On 3/30/20 08:38, Luigi Tagliafierro wrote: > we have already tried to implement the legacy cookie processor but > with no result. What did you actually do? What was the actual result? I suspect that because: 1. The cookie domain is invalid 2. This error has been present "for a long time" 3. Nobody seems to have noticed This means that your cookie has never been working and nobody cares about it. Perhaps whatever is using this cookie can simply be removed from your application? - -chris > Da: calder > Inviato: lunedì 30 marzo 2020 13:14 A: Tomcat Users List > Cc: Alessio Torelli > Oggetto: Re: Support with error in launcher.log > > On Mon, Mar 30, 2020, 05:02 Luigi Tagliafierro > wrote: > >> Hi everybody, >> >> we are experiencing an error : The bitbucket log >> (/var/atlassian/bitbucket_home/log/launcher.log) constantly >> repeats this error: >> >> "java.lang.IllegalArgumentException: An invalid domain >> > > > [.code.doxee.com] was specified for this cookie" . >> > > Issue: the domain has a dot (.) at its beginning. > > > The error has been present in the log for some time and continues > to be. >> >> We contacted the support of atlassian, who after an analysis >> suggested that we ask you about the error in question. Here the >> link to the discussion, *and all the info, tests and steps we >> took before contacting you* : >> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-4 2041 >> >> >> Our Tomcat version is: 8.5.29 >> >> In attachment there is the complete error. >> >> We are waiting for an answer that can help you analyze or solve >> the problem, >> >> Thanks a lot, Regards, >> >> Luigi >> > >> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6CFncACgkQHPApP6U8 pFi5iQ/+MA+SH5fBwa6NMXU4z3yslP+6B9l9S5bI1WIDwsx7NfT8buuULekpVHv3 kZt3kmiNL0p1ViWynZJdbw8a+Rd1jub2YpjniYzpjEOdbGksctCka1PRdf5SJ01r ZHq9cUvG1oEGoqWwbZoxo2dsKNi6uNOwBvb1WiIrVvvzU8ZWZVTo+TaUCmd1U684 3TfYejhQ7PPI//rElP7638XzlZdlk/odwYJSqui1t9bfCOcaWzI9Zut9WoI6+scs tviakF7dlNM6JjFZVi/+gQiCCcF+xM2tfYEX39gHGedy0ZHYeJnnqSmwlwu9GqsQ vVQr2j1CZCRqqjSIwGCvHg6U+YbpdgySKD0doutTTDNcGABN0KmWZxDY7HPAui5l tWoByWy3Rt+7i9TPyJnEwcD2l0XNkmUwiLHAFTwPev7E2qQ1vxG3SU6nLd6SS5I/ a/hj2SGjSziwvDK9vCFSL2up/Eqc2A8VW2s63i9MPvx1PAeRmyyIyTe3BWPKpVe7 VuWK2rnVjLpD5jM5BhyJqpZyXWAYV0Qp8TwdNFBmSd4h7rHFH7ZgzXF3yVeWh3AA NKg75j6IXk9a4Leju74rmi9iTpKUAxY4MabF9T0S+oPy0wlvZ3HyTQE1XanguUVQ 9WxoldF2NaZpf80v34GAjGHmqvhU1cN02m/kXUzO7PmhmYKmYb8= =NhFz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat7 does not log x-forwarded-for
Hello all, I currently have a problem with Tomcat7, or rather a colleague has it. Personally I would like to help him, but I can't find the error myself. We already asked the question on stackoverflow.com and got a good hint, but unfortunately no solving. So I would like to ask for help and support here. I think I am violating the directive of asking a double question, but it is important to me personally to help this colleague. Therefore I am at least honest, the question can also be found at the link: https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-doesnt-work-with-load-balancer We run a software that uses Tomcat as application server behind a load balancer. Now we would like to record the initial address of the requests and not the IP of the load balancer. We have used these 3 websites for the setup, but unfortunately it does not work. The IPs of the loadbalancers are still written to the access log. https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/AccessLogValve.html https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve We used the following configuration for access logging and remote valve: The request header 'X-Forwarded-For' was set and load balancer was analyzed via wireshark and Request Dumper Filter. We can see the header in both. However we still only get the IP of the load balancer and not the IP of the remote client. The IP adresses of the config have already been checked and they are correct. Thank you very much in advance for your support. With kindest regards Frank - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
