回复: getServerPort always return 80
Hi chris, > I use httpServletRequest.getServerPort() to get the port in my jsp. > When the tomcat listen 8080 and nginx listen 80. > Nginx has set ‘proxy_set_header Host $http_host’. > What is the value of $http_host? The $http_host is ‘externalIP:10001’ (I print it in access_log of nginx to make sure that it is a correct valve.) I use httpServletRequest.getHeader(“Host”) in java and it can print the right value too. But as I know the getServerPort should print the number after ‘:’ of ‘Host’ Header. So I don’t know what’s the wrong. And today I found another similar situation. The server has a Internet IP and Tomcat listening 8080 and nginx listening 81. So there are no port mapping. At this time getServerPort() still return 80. > Then the port 80 mapping to Internet via 10001. > Use httpServletRequest.getHeader(“Host”) I can get the correct value of Host > header �C “InternetIP:10001”. > But httpServletRequest.getServerPort() did not return 10001 and return 80. > How could I solve it？ > Btw, to set proxyPort in connector can not take effect. But proxyName work. > Have you read about the RemoteIPValve? The RemoteIPValve seems to be used for get the real client IP, but I just need to get the correct port which client use to visit my website. Forgive my poor English and I hope you can understand what I say. (＾－＾) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
HTTP2 : WINDOW_UPDATE not sent on stream level
Hi Team, On sending 3 requests of around 3KB size , we see that only the first request has processed fine. The other 2 requests are waiting for more Data as tomcat has not responded with WINDOW_UPDATE on stream level . Please help us understand this behavior . Embedded tomcat version : 9.0.56 The initial window size is set to 500, all other params are the tomcat defaults . HTTP2 port : 1080 Client : JMeter I have placed the reproducer , debug logs ,PCAP and JMX where we have tested with version 9.0.56 here : https://drive.google.com/file/d/1u4Sc_7oSB9tdJN8ls9xTMrRqP8IFoACM/view?usp=sharing The same JMX works fine with the overhead values changed to zero. Will we have any side effects on changing the overhead parameters to zero? Thanks in Advance! Regards Arshiya Shariff
Re: tomcat 7 slow to deploy web applications on m1 mac
On Tue, Jan 4, 2022 at 2:50 PM Mark Thomas wrote: > > > On 04/01/2022 19:23, Robert J. Carr wrote: > > I've been using tomcat for many years but unfortunately I'm stuck on > > version 7 (long story). I recently picked up a new workstation, an Apple > > M1 MacBook (M1 Max - macOS 12.1), and I installed the ARM version of Azul > > Zulu (1.8.0_312), and by all accounts everything is really fast, as you'd > > expect. A compile that took about 3.5 minutes on a 2016 x86 MacBook now > > takes about 50 seconds on ARM. > > > > However, deploying web applications (context deploy via web service) is > > much slower compared to x86. One app used to take about 3-4 seconds and > > the other near instantaneous are now taking 42 and 11 seconds, > > respectively, and very consistently. The same is true for tomcat > restarts > > when the custom apps are registered. Without any custom apps tomcat > starts > > in under one second. App reloads are a bit faster than deploy, but still > > very slow compared to x86. The only thing different I can tell is the > > workstation (and thus, architecture). > > > > I started on Tomcat version 7.0.109 (newest at the time), but reverted > to a > > known working 7.0.76 thinking it might be the issue, but nothing changed, > > i.e., still noticing the huge delay during deployment, down to the same > > amount of delay time. > > > > The only noticeable issue in the logs is this line: > > > >> At least one JAR was scanned for TLDs yet contained no TLDs. Enable > debug > > logging for this logger for a complete list of JARs that were scanned but > > no TLDs were found in them. > > > > This was also in the x86 logs that I never addressed, so I think it's a > red > > herring; however, when monitoring the logs after a deploy, that is the > last > > line printed before it idles for 10-40 seconds. Also, the application > with > > more jar files is the one that takes longer to start, so I thought I'd > > investigate. > > > > I started by adding this to 'logging.properties' > > > > org.apache.jasper.compiler.TldLocationsCache.level = FINE > > > > But nothing new was printed, even when setting to FINEST. Researching > > around, and reading 'catalina.properties', I added all of the jars from > the > > web application to this property: > > > > org.apache.catalina.startup.TldConfig.jarsToSkip=... > > > > And the TLD warning went away, but the long multi-second pause persisted. > > Searching around more, I came across this document: > > > > > https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp > > > > I had already added the entropy fix to my startup script (and I don't see > > any SecureRandom warnings in the logs): > > > > -Djava.security.egd=file:/dev/./urandom > > > > So that doesn't appear to be related to my issue. > > > > As I said, my config is now exactly the same as it was on x86, so > anything > > new I try from here is just completely guessing. I'm hoping somebody has > > an idea so I can stop guessing. > > > > Please let me know if there's any information that would help, but I > tried > > to provide all of the relevant details I know of. > > My usual advice is to get a profiler and see what is going on. > > I use YourKit - primarily because they give me a free license to use for > Tomcat development. Other profilers are available. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Hi Mark- Thanks so much for the profiler recommendation; I'm old enough that I should have considered this, but I thought it was some deep issue with tomcat related somehow to the new architecture. Turns out I was wrong. The issue was actually from doing an 'InetAddress.getLocalHost()' call, from within log4j, and this was causing a 5 second timeout. My guess is log4j is making this call once per logger/appender, and since my larger application has more of these, that's why it was taking so much longer for that one. So why is it timing out? Seems to be a peculiarity with java 8 and macOS and looks to still exist. See here: https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds https://stackoverflow.com/questions/39636792/jvm-takes-a-long-time-to-resolve-ip-address-for-localhost/39698914#39698914 Since this is a new workstation I hadn't touched the hosts file and that was the difference compared to my previous config (which I must have set just by coincidence). So, false alarm, nothing to do with tomcat, but thanks again for leading me in the right direction! Cheers- Robert
Re: tomcat 7 slow to deploy web applications on m1 mac
On Tue, Jan 4, 2022 at 2:50 PM Mark Thomas wrote: > > On 04/01/2022 19:23, Robert J. Carr wrote: > > I've been using tomcat for many years but unfortunately I'm stuck on > > version 7 (long story). I recently picked up a new workstation, an Apple > > M1 MacBook (M1 Max - macOS 12.1), and I installed the ARM version of Azul > > Zulu (1.8.0_312), and by all accounts everything is really fast, as you'd > > expect. A compile that took about 3.5 minutes on a 2016 x86 MacBook now > > takes about 50 seconds on ARM. > > > > However, deploying web applications (context deploy via web service) is > > much slower compared to x86. One app used to take about 3-4 seconds and > > the other near instantaneous are now taking 42 and 11 seconds, > > respectively, and very consistently. The same is true for tomcat > restarts > > when the custom apps are registered. Without any custom apps tomcat > starts > > in under one second. App reloads are a bit faster than deploy, but still > > very slow compared to x86. The only thing different I can tell is the > > workstation (and thus, architecture). > > > > I started on Tomcat version 7.0.109 (newest at the time), but reverted > to a > > known working 7.0.76 thinking it might be the issue, but nothing changed, > > i.e., still noticing the huge delay during deployment, down to the same > > amount of delay time. > > > > The only noticeable issue in the logs is this line: > > > >> At least one JAR was scanned for TLDs yet contained no TLDs. Enable > debug > > logging for this logger for a complete list of JARs that were scanned but > > no TLDs were found in them. > > > > This was also in the x86 logs that I never addressed, so I think it's a > red > > herring; however, when monitoring the logs after a deploy, that is the > last > > line printed before it idles for 10-40 seconds. Also, the application > with > > more jar files is the one that takes longer to start, so I thought I'd > > investigate. > > > > I started by adding this to 'logging.properties' > > > > org.apache.jasper.compiler.TldLocationsCache.level = FINE > > > > But nothing new was printed, even when setting to FINEST. Researching > > around, and reading 'catalina.properties', I added all of the jars from > the > > web application to this property: > > > > org.apache.catalina.startup.TldConfig.jarsToSkip=... > > > > And the TLD warning went away, but the long multi-second pause persisted. > > Searching around more, I came across this document: > > > > > https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp > > > > I had already added the entropy fix to my startup script (and I don't see > > any SecureRandom warnings in the logs): > > > > -Djava.security.egd=file:/dev/./urandom > > > > So that doesn't appear to be related to my issue. > > > > As I said, my config is now exactly the same as it was on x86, so > anything > > new I try from here is just completely guessing. I'm hoping somebody has > > an idea so I can stop guessing. > > > > Please let me know if there's any information that would help, but I > tried > > to provide all of the relevant details I know of. > > My usual advice is to get a profiler and see what is going on. > > I use YourKit - primarily because they give me a free license to use for > Tomcat development. Other profilers are available. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Good suggestion, thanks! I’ll report back what I discover. -- Thanks- Robert
Re: tomcat 7 slow to deploy web applications on m1 mac
On 04/01/2022 19:23, Robert J. Carr wrote: I've been using tomcat for many years but unfortunately I'm stuck on version 7 (long story). I recently picked up a new workstation, an Apple M1 MacBook (M1 Max - macOS 12.1), and I installed the ARM version of Azul Zulu (1.8.0_312), and by all accounts everything is really fast, as you'd expect. A compile that took about 3.5 minutes on a 2016 x86 MacBook now takes about 50 seconds on ARM. However, deploying web applications (context deploy via web service) is much slower compared to x86. One app used to take about 3-4 seconds and the other near instantaneous are now taking 42 and 11 seconds, respectively, and very consistently. The same is true for tomcat restarts when the custom apps are registered. Without any custom apps tomcat starts in under one second. App reloads are a bit faster than deploy, but still very slow compared to x86. The only thing different I can tell is the workstation (and thus, architecture). I started on Tomcat version 7.0.109 (newest at the time), but reverted to a known working 7.0.76 thinking it might be the issue, but nothing changed, i.e., still noticing the huge delay during deployment, down to the same amount of delay time. The only noticeable issue in the logs is this line: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. This was also in the x86 logs that I never addressed, so I think it's a red herring; however, when monitoring the logs after a deploy, that is the last line printed before it idles for 10-40 seconds. Also, the application with more jar files is the one that takes longer to start, so I thought I'd investigate. I started by adding this to 'logging.properties' org.apache.jasper.compiler.TldLocationsCache.level = FINE But nothing new was printed, even when setting to FINEST. Researching around, and reading 'catalina.properties', I added all of the jars from the web application to this property: org.apache.catalina.startup.TldConfig.jarsToSkip=... And the TLD warning went away, but the long multi-second pause persisted. Searching around more, I came across this document: https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp I had already added the entropy fix to my startup script (and I don't see any SecureRandom warnings in the logs): -Djava.security.egd=file:/dev/./urandom So that doesn't appear to be related to my issue. As I said, my config is now exactly the same as it was on x86, so anything new I try from here is just completely guessing. I'm hoping somebody has an idea so I can stop guessing. Please let me know if there's any information that would help, but I tried to provide all of the relevant details I know of. My usual advice is to get a profiler and see what is going on. I use YourKit - primarily because they give me a free license to use for Tomcat development. Other profilers are available. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 7 slow to deploy web applications on m1 mac
I've been using tomcat for many years but unfortunately I'm stuck on version 7 (long story). I recently picked up a new workstation, an Apple M1 MacBook (M1 Max - macOS 12.1), and I installed the ARM version of Azul Zulu (1.8.0_312), and by all accounts everything is really fast, as you'd expect. A compile that took about 3.5 minutes on a 2016 x86 MacBook now takes about 50 seconds on ARM. However, deploying web applications (context deploy via web service) is much slower compared to x86. One app used to take about 3-4 seconds and the other near instantaneous are now taking 42 and 11 seconds, respectively, and very consistently. The same is true for tomcat restarts when the custom apps are registered. Without any custom apps tomcat starts in under one second. App reloads are a bit faster than deploy, but still very slow compared to x86. The only thing different I can tell is the workstation (and thus, architecture). I started on Tomcat version 7.0.109 (newest at the time), but reverted to a known working 7.0.76 thinking it might be the issue, but nothing changed, i.e., still noticing the huge delay during deployment, down to the same amount of delay time. The only noticeable issue in the logs is this line: > At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. This was also in the x86 logs that I never addressed, so I think it's a red herring; however, when monitoring the logs after a deploy, that is the last line printed before it idles for 10-40 seconds. Also, the application with more jar files is the one that takes longer to start, so I thought I'd investigate. I started by adding this to 'logging.properties' org.apache.jasper.compiler.TldLocationsCache.level = FINE But nothing new was printed, even when setting to FINEST. Researching around, and reading 'catalina.properties', I added all of the jars from the web application to this property: org.apache.catalina.startup.TldConfig.jarsToSkip=... And the TLD warning went away, but the long multi-second pause persisted. Searching around more, I came across this document: https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp I had already added the entropy fix to my startup script (and I don't see any SecureRandom warnings in the logs): -Djava.security.egd=file:/dev/./urandom So that doesn't appear to be related to my issue. As I said, my config is now exactly the same as it was on x86, so anything new I try from here is just completely guessing. I'm hoping somebody has an idea so I can stop guessing. Please let me know if there's any information that would help, but I tried to provide all of the relevant details I know of. Thanks! Robert
Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
Eric, On 1/4/22 00:08, Eric Robinson wrote: We have access to the configuration files, but not the source code. There is no "pool" reference in server.xml or any of the context.xml files. You would want to look for . However, I did receive a call from a vendor tech this morning and they are exploring the question right now and will get back to me soon hopefully. Sounds hopeful. I'd be interested to hear what the original justification was for not using pooling. -chris -Original Message- From: Christopher Schultz Sent: Monday, January 3, 2022 9:10 AM To: users@tomcat.apache.org Subject: Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem? Eric, On 12/30/21 19:03, Eric Robinson wrote: If I want to ignore the vendor's recommendation and try connection pooling anyway, is that something I can enable with a config file setting, or do they actually have to trigger it from within their code? That depends upon how they are obtaining database connections. If they are using the driver directly and NOT using a pool (why would they use a pool if they have a policy NOT to use it?) then there is likely nothing you can do. Are you able to look at the code? Are you able to look at the configuration? Specifically, the META-INF/context.xml file in the application and conf/server.xml for the server. If we can find a "pool" configuration in there, it's possible it just has insane limits like maxActive="10" or something like that. -chris -Original Message- From: Eric Robinson Sent: Thursday, December 30, 2021 12:00 PM To: Tomcat Users List Subject: RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem? Chris, Not pooling connections will very likely negatively affect performance. When you say "they ... have an issue with connection pooling" do you mean that they have a technical problem, or do you mean that there is some ill- conceived policy against them? Oh, maybe they are paranoid about cross-client leakage between connections. Well, if the application can't be trusted not to leak that kind of info, then it can't be trusted to make the connections properly in the first place. -chris Hard to say what their issue is. We've asked about implementing it before, but they don't support it. You know how software companies are. Maybe they had a technical problem with it years ago and have just not revisited it. They're stuck in a rut and there is too much inertia to get them out of it. --Eric Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. - 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 Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To
Re: getServerPort always return 80
王 静凯, On 1/4/22 00:46, 王 静凯 wrote: Hi, I use httpServletRequest.getServerPort() to get the port in my jsp. When the tomcat listen 8080 and nginx listen 80. Nginx has set ‘proxy_set_header Host $http_host’. What is the value of $http_host? Then the port 80 mapping to Internet via 10001. Use httpServletRequest.getHeader(“Host”) I can get the correct value of Host header – “InternetIP:10001”. But httpServletRequest.getServerPort() did not return 10001 and return 80. How could I solve it？ Btw, to set proxyPort in connector can not take effect. But proxyName work. Have you read about the RemoteIPValve? Using tomcat 8.5.72 and jre 1.8.0_201 on CentOS7.2009 My server.xml: getServerPort int getServerPort() Returns the port number to which the request was sent. It is the value of the part after ":" in the Host header value, if any, or the server port where the client connection was accepted on. Returns: an integer specifying the port number Can you dump the values of ALL headers on the Tomcat side and post them? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues when building native image with GraalVM
On Fri, Dec 31, 2021 at 2:47 PM Mar R wrote: > > I forgot something sorry. Maybe I'm missing something important but, about > classloading, on native image shouldn't it NOT exist? As far as I > understood after you have a native image you have (resources a part) > everything you need inside the binary + libraries, in my case .exe and .dll > files. > Unless I missed something and a graal native image has a jvm or sort of > which will actually run, so now i get why java code outside of the binary > will actually be used, BUT then I don't get why it was designed this way, > this isn't AOT anymore Tomcat is a Jakarta EE container, so it does that and runs regular webapps (the main big difference is that the JSPs of the webapp have to be precompiled - luckily this has been a feature for a while). Graal doesn't remove classloading anyway, the webapp initialization is the same, and all components are loaded dynamically from descriptors or annotations. If you don't like that, then you have to look at a framework targeted at making native images. My employer happens to make Quarkus. As for the issues, you should close https://github.com/oracle/graal/issues/4164 I fixed the following issues (will be in the next releases in January): - Packaging some now missing resource bundles (you can ignore warnings like this) - Better escaping for call method rules argument values in generated code (this causes a problem with your Windows paths with the watched resources) I don't understand what you mean about the problem with ServletContextListener. I don't understand why there would be a problem with that. Please try to debug it further if you can. About JMX, Tomcat uses JMX and has it enabled by default. You can disable JMX use in Tomcat with --no-jmx (until recently this was done internally in Tomcat when using AOT). Rémy > > Il giorno ven 31 dic 2021 alle ore 14:42 Mar R > ha scritto: > > > Il giorno mar 28 dic 2021 alle ore 22:26 Rémy Maucherat > > ha scritto: > > > >> On Tue, Dec 28, 2021 at 7:18 PM Mar R wrote: > >> > > >> > Tomcat 10.0.14 > >> > Windows 10 x64 21H1 OS Build 19043.1415 > >> > > >> > openjdk version "17.0.1" 2021-10-19 > >> > OpenJDK Runtime Environment GraalVM CE 21.3.0 (build > >> > 17.0.1+12-jvmci-21.3-b05) > >> > OpenJDK 64-Bit Server VM GraalVM CE 21.3.0 (build > >> 17.0.1+12-jvmci-21.3-b05, > >> > mixed mode, sharing) > >> > > >> > NetBeans 12.6, maven webapp project > >> > Maven 3.8.4 > >> > Ant 1.10.12 > >> > > >> > Followed guide at https://tomcat.apache.org/tomcat-10.0-doc/graal.html > >> > > >> > Sorry in advance if not all issues should be reported here but instead > >> are > >> > graalvm native image related, I'm reporting everything here and on their > >> > github fro completeness. > >> > > >> > > >> https://drive.google.com/file/d/17flFW5nlNCdojlvJxCOy23NJBj03p46u/view?usp=sharing > >> > In this link you can find a folder with everything I used from tomcat > >> > stuffed folder downloaded from the github link present in the tomcat AOT > >> > guide, to all commands I put in a script for easier testing purpose, > >> source > >> > webapp, built webapp, screenshots, everything :D > >> > > >> > I'll start by saying I'm well aware I could definitely have overlooked > >> > something, anyway I managed to get to the final native image and it > >> works, > >> > BUT: > >> > > >> > If you remove .class files from webapps/webappname folder, when you run > >> the > >> > binary file, it won't find those files, only jsps. This is strange > >> because > >> > those files are actually present in the fat jar, and this actually beats > >> > the purpose of builidng a native image if you have to ship it with java > >> > files. > >> > > >> > If there is a class extending ServletContextListener (InitClass in this > >> > webapp), when running command with "--catalina -generateCode" parameter, > >> > where you have to access all jsps and servlets, the class extending > >> > ServletContextListener will be initialized/used(?) like 2 times, but the > >> > second time not completly, resetting everything done in the first > >> > initialization. > >> > In this webapp it happens when you access the only servlet present. > >> > Anyway all code is in the google drive link and in InitClass i put some > >> > prints so you can see what I mean. > >> > In another bigger webapp my InitClass initializes a lot of things used > >> by > >> > the webapp basically screwing it. > >> > This issues happens only in this phase becasue in the second phase where > >> > the parameter is "useGeneratedCode" it works normally both with this > >> simple > >> > test webapp and in my other one > >> > > >> > When building with native-image command, if > >> > "-J--add-exports=java.management/sun.management=ALL-UNNAMED" isn't used > >> as > >> > additional parameter, errors will pop on run crashing the app. > >> (screenshot > >> > in the google drive link) > >> > >> Before looking at it more deeply (later ...), let's take this step by > >>
