RE: RemoteIpValve resolving localname is really slow
> -Message d'origine- > De : Konstantin Kolinko > Envoyé : lundi 12 avril 2021 17:10 > À : users@tomcat.apache.org > Objet : Re: RemoteIpValve resolving localname is really slow > > пн, 12 апр. 2021 г. в 16:50, Bourdais Nicolas > : > > > > We are hosting our tomcats on windows vms behind a reverse proxy and have > enabled RemoteIPValve. > > In the same time we have many hardware which talk to tomcat through a > vpn. > > Recently we updated our tomcats to a more recent version (8.5.43 to 8.5.53) > and our apps running on hardware through vpn had difficulties to talk to > tomcat. > > > > We identified that these difficulties came from very slow localname > resolution in RemoteIpValve when calling through vpn. > > We added vpn IP to hosts file of our tomcat’s vms which resolved our errors. > > > > We found that these behaviour appeared with tomcat 8.5.44 and was a > consequence of the new feature in RemoteIPValve and RemoteIpFilter : > 'support x-forwarded-host’ id 57665. > > Since this feature the valve begins by resolving localname (along > > remoteAddr, remoteHost, serverName etc…) which in our case is time > > consuming (> 5 s) and leads to communication errors > > > > Is this behaviour expected and necessary ? > > Could localName be resolved only if changeLocalName is set to true ? > > Should I comment on bugzilla ? > > 1. What is the configuration of your valve and your connectors? > Valve configuration is the default one. Here is the full configuration > By default Tomcat does not perform a DNS lookup and thus there should not be > noticeable timeouts. Can you show a stacktrace, what actually happens. > > https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Di > agnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario > I would'nt say that Tomcat perform a DNS lookup. It's a native call that is performed by the following stack. We made a yourkit profiling to find out why requests were longer than a previous tomcat. java.net.Inet6AddressImpl.getHostByAddr(byte[]) Inet6AddressImpl.java (native) java.net.InetAddress$2.getHostByAddr(byte[]) InetAddress.java:933 java.net.InetAddress.getHostFromNameService(InetAddress, boolean) InetAddress.java:618 java.net.InetAddress.getHostName(boolean) InetAddress.java:560 java.net.InetAddress.getHostName() InetAddress.java:532 org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.populateLocalName() NioEndpoint.java:1395 org.apache.tomcat.util.net.SocketWrapperBase.getLocalName() SocketWrapperBase.java:231 org.apache.coyote.AbstractProcessor.action(ActionCode, Object) AbstractProcessor.java:473 org.apache.coyote.Request.action(ActionCode, Object) Request.java:433 org.apache.catalina.connector.Request.getLocalName() Request.java:1335 org.apache.catalina.valves.RemoteIpValve.invoke(Request, Response) RemoteIpValve.java:610 org.apache.catalina.connector.CoyoteAdapter.service(Request, Response) CoyoteAdapter.java:343 org.apache.coyote.http11.Http11Processor.service(SocketWrapperBase) Http11Processor.java:615 org.apache.coyote.AbstractProcessorLight.process(SocketWrapperBase, SocketEvent) AbstractProcessorLight.java:65 org.apache.coyote.AbstractProtocol$ConnectionHandler.process(SocketWrapperBase, SocketEvent) AbstractProtocol.java:818 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun() NioEndpoint.java:1623 org.apache.tomcat.util.net.SocketProcessorBase.run() SocketProcessorBase.java:49 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) ThreadPoolExecutor.java:1149 java.util.concurrent.ThreadPoolExecutor$Worker.run() ThreadPoolExecutor.java:624 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run() TaskThread.java:61 java.lang.Thread.run() Thread.java:748 When I try to resolve localname by addr like what is called at java.net.InetAddress$2.getHostByAddr(byte[]) outside of tomcat, in a powershell, I get the same delay as in tomcat. > 2. If one could confirm your trouble, it would better be filed as a new issue > in > Bugzilla. > > Best regards, > Konstantin Kolinko > > - > 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: RemoteIpValve resolving localname is really slow
> -Message d'origine- > De : Felix Schumacher > Envoyé : lundi 12 avril 2021 16:55 > À : users@tomcat.apache.org > Objet : Re: RemoteIpValve resolving localname is really slow > > > Am 12.04.21 um 15:49 schrieb Bourdais Nicolas: > > We are hosting our tomcats on windows vms behind a reverse proxy and have > enabled RemoteIPValve. > > In the same time we have many hardware which talk to tomcat through a > vpn. > > Recently we updated our tomcats to a more recent version (8.5.43 to 8.5.53) > and our apps running on hardware through vpn had difficulties to talk to > tomcat. > > > > We identified that these difficulties came from very slow localname > resolution in RemoteIpValve when calling through vpn. > > We added vpn IP to hosts file of our tomcat’s vms which resolved our errors. > > > > We found that these behaviour appeared with tomcat 8.5.44 and was a > consequence of the new feature in RemoteIPValve and RemoteIpFilter : > 'support x-forwarded-host’ id 57665. > > Since this feature the valve begins by resolving localname (along > > remoteAddr, remoteHost, serverName etc…) which in our case is time > > consuming (> 5 s) and leads to communication errors > > > > Is this behaviour expected and necessary ? > > Could localName be resolved only if changeLocalName is set to true ? > > How is your connector configured? Has it an attribute enableLookups (set to > true)? > No it doesn't. Here is the configuration: Nicolas > Felix > > > Should I comment on bugzilla ? > > > > > > Ce message et toutes les pieces jointes (ci-apres le "message") sont > > etablis a > l'intention exclusive de ses destinataires. > > Si vous recevez ce message par erreur, merci de le detruire et d'en avertir > immediatement l'expediteur par e-mail. > > Toute utilisation de ce message non conforme a sa destination, toute > diffusion ou toute publication, totale ou partielle, est interdite, sauf > autorisation > expresse. Les communications sur Internet n'etant pas securisees, l'expediteur > informe qu'il ne peut accepter aucune responsabilite quant au contenu de ce > message. > > This mail message and attachments (the "message") are solely intended for > the addresses. It is confidential in nature. > > If you receive this message in error, please delete it and immediately > > notify > the sender by e-mail. > > Any use other than its intended purpose, dissemination or disclosure, either > whole or partial, is prohibited except if formal approval is granted. As > communication on the Internet is not secure, the sender does not accept > responsibility for the content of this message. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: RemoteIpValve resolving localname is really slow
пн, 12 апр. 2021 г. в 16:50, Bourdais Nicolas : > > We are hosting our tomcats on windows vms behind a reverse proxy and have > enabled RemoteIPValve. > In the same time we have many hardware which talk to tomcat through a vpn. > Recently we updated our tomcats to a more recent version (8.5.43 to 8.5.53) > and our apps running on hardware through vpn had difficulties to talk to > tomcat. > > We identified that these difficulties came from very slow localname > resolution in RemoteIpValve when calling through vpn. > We added vpn IP to hosts file of our tomcat’s vms which resolved our errors. > > We found that these behaviour appeared with tomcat 8.5.44 and was a > consequence of the new feature in RemoteIPValve and RemoteIpFilter : 'support > x-forwarded-host’ id 57665. > Since this feature the valve begins by resolving localname (along remoteAddr, > remoteHost, serverName etc…) which in our case is time consuming (> 5 s) and > leads to communication errors > > Is this behaviour expected and necessary ? > Could localName be resolved only if changeLocalName is set to true ? > Should I comment on bugzilla ? 1. What is the configuration of your valve and your connectors? By default Tomcat does not perform a DNS lookup and thus there should not be noticeable timeouts. Can you show a stacktrace, what actually happens. https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario 2. If one could confirm your trouble, it would better be filed as a new issue in Bugzilla. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RemoteIpValve resolving localname is really slow
Am 12.04.21 um 15:49 schrieb Bourdais Nicolas: > We are hosting our tomcats on windows vms behind a reverse proxy and have > enabled RemoteIPValve. > In the same time we have many hardware which talk to tomcat through a vpn. > Recently we updated our tomcats to a more recent version (8.5.43 to 8.5.53) > and our apps running on hardware through vpn had difficulties to talk to > tomcat. > > We identified that these difficulties came from very slow localname > resolution in RemoteIpValve when calling through vpn. > We added vpn IP to hosts file of our tomcat’s vms which resolved our errors. > > We found that these behaviour appeared with tomcat 8.5.44 and was a > consequence of the new feature in RemoteIPValve and RemoteIpFilter : 'support > x-forwarded-host’ id 57665. > Since this feature the valve begins by resolving localname (along remoteAddr, > remoteHost, serverName etc…) which in our case is time consuming (> 5 s) and > leads to communication errors > > Is this behaviour expected and necessary ? > Could localName be resolved only if changeLocalName is set to true ? How is your connector configured? Has it an attribute enableLookups (set to true)? Felix > Should I comment on bugzilla ? > > > Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis > a l'intention exclusive de ses destinataires. > Si vous recevez ce message par erreur, merci de le detruire et d'en avertir > immediatement l'expediteur par e-mail. > Toute utilisation de ce message non conforme a sa destination, toute > diffusion ou toute publication, totale ou partielle, est interdite, sauf > autorisation expresse. Les communications sur Internet n'etant pas > securisees, l'expediteur informe qu'il ne peut accepter aucune responsabilite > quant au contenu de ce message. > This mail message and attachments (the "message") are solely intended for the > addresses. It is confidential in nature. > If you receive this message in error, please delete it and immediately notify > the sender by e-mail. > Any use other than its intended purpose, dissemination or disclosure, either > whole or partial, is prohibited except if formal approval is granted. As > communication on the Internet is not secure, the sender does not accept > responsibility for the content of this message. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > OpenPGP_signature Description: OpenPGP digital signature
