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
RemoteIpValve resolving localname is really slow
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 ? 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.
