AW: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null
Note: I have moved this "issue" over to the tomcat-dev mailinglist ... -Ursprüngliche Nachricht- Von: Clemens Wyss DEV Gesendet: Mittwoch, 24. Juli 2019 11:07 An: 'Tomcat Users List' Betreff: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null Context: Debian GNU/Linux 9 \n \l java version 1.8.0_162 Tomcat 8.5.35 From time to time we are facing the follwing exception (call stack): ... Caused by: java.sql.SQLException: Unable to load class: org.mariadb.jdbc.Driver from ClassLoader:java.net.URLClassLoader@4c873330;ClassLoader:null at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:292) at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212) at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:736) at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:668) at org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:198) at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:132) at org.apache.torque.Torque.getConnection(Torque.java:924) ... 53 common frames omitted Caused by: java.lang.ClassNotFoundException: Unable to load class: org.mariadb.jdbc.Driver from ClassLoader:java.net.URLClassLoader@4c873330;ClassLoader:null at org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:56) at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:280) ... 59 common frames omitted Caused by: java.lang.ClassNotFoundException: Classloader is null at org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:40) ... 60 common frames omitted According to the code (in PooledConnection# connectUsingDriver) Thread.currentThread().getContextClassLoader() returns null Googling for " Thread.currentThread().getContextClassLoader() is null" the common demoniator seems to be `getContextClassLoader can be null`. If this is true there should be a) a null-check in PooledConnection# connectUsingDriver b) if null, then there should be a fallback-Classloader (the system class laoder?) WDYT ? Or any ideas why the given exception pops up from time to time Thx Clemens B�CB�� [��X��ܚX�KK[XZ[ � \�\��][��X��ܚX�P �X�] �\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[ � \�\��Z[ �X�] �\X�K�ܙ�B� - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null
Context: Debian GNU/Linux 9 \n \l java version 1.8.0_162 Tomcat 8.5.35 From time to time we are facing the follwing exception (call stack): ... Caused by: java.sql.SQLException: Unable to load class: org.mariadb.jdbc.Driver from ClassLoader:java.net.URLClassLoader@4c873330;ClassLoader:null at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:292) at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212) at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:736) at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:668) at org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:198) at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:132) at org.apache.torque.Torque.getConnection(Torque.java:924) ... 53 common frames omitted Caused by: java.lang.ClassNotFoundException: Unable to load class: org.mariadb.jdbc.Driver from ClassLoader:java.net.URLClassLoader@4c873330;ClassLoader:null at org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:56) at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:280) ... 59 common frames omitted Caused by: java.lang.ClassNotFoundException: Classloader is null at org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:40) ... 60 common frames omitted According to the code (in PooledConnection# connectUsingDriver) Thread.currentThread().getContextClassLoader() returns null Googling for " Thread.currentThread().getContextClassLoader() is null" the common demoniator seems to be `getContextClassLoader can be null`. If this is true there should be a) a null-check in PooledConnection# connectUsingDriver b) if null, then there should be a fallback-Classloader (the system class laoder?) WDYT ? Or any ideas why the given exception pops up from time to time Thx Clemens
AW: AW: jk_handler::mod_jk.c (2917): Could not get endpoint for worker ...
> your httpd nodes (I guess just 1) Just to clarify. We have one apache-httpd (and one tomcat) running. >tomcat tomcat-8.5.28 >connector-impl I'd say we are using nio ... 09-Aug-2018 19:54:31.181 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based Apache Tomcat Native library [1.2.16] using APR version [1.6.3]. 09-Aug-2018 19:54:31.181 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 09-Aug-2018 19:54:31.181 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] 09-Aug-2018 19:54:31.185 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.0.2n 7 Dec 2017] 09-Aug-2018 19:54:31.608 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-8009"] ... 09-Aug-2018 19:55:36.046 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"] ... -Ursprüngliche Nachricht- Von: Christopher Schultz Gesendet: Montag, 17. September 2018 20:36 An: users@tomcat.apache.org Betreff: Re: AW: jk_handler::mod_jk.c (2917): Could not get endpoint for worker ... -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 9/17/18 02:54, Clemens Wyss DEV wrote: >> How many httpd nodes? > 1 Ok. >> Which MPM? > Tried worker and event These should have roughly the same semantics. >> Per MPM, what is MaxClients, etc.? > MaxRequestWorkers 512 ThreadsPerChild32 So the maximum number of simultaneous connections your httpd nodes (I guess just 1) will try to send to the backend Tomcat node will be 512 based upon MaxRequestWorkers. >> How many Tomcat nodes? > 1 > >> Tomcat connector configuration? > maxThreads="400" protocol="AJP/1.3" /> So you can have 512 AJP connections from httpd connecting to Tomcat which has 400 threads and, depending upon which connector is actually in use, you may be limited to 400 connections or 10,000. Based upon your situation, I'd say you are using Java BIO and are thus limited to 400 connections. What version of Tomcat are you using? What connector eventually gets used? There are several: Java BIO Java NIO Java NIO2 APR You can tell from the startup messages what kind of connector you get; it's shown when the connector starts and emits an INFO message saying that it's configured. - -chris > -Ursprüngliche Nachricht- Von: Christopher Schultz > Gesendet: Sonntag, 16. September > 2018 20:42 An: users@tomcat.apache.org Betreff: Re: > jk_handler::mod_jk.c (2917): Could not get endpoint for worker ... > > Clemens, > > On 9/15/18 06:50, Clemens Wyss DEV wrote: >> Hi all, we are seeing quite a few: "[Mon Sep 10 15:19:46 2018] >> [27562:140532026529536] [error] jk_handler::mod_jk.c (2917): >> Could not get endpoint for worker=testAPJ" > >> errors in our md_jk.log. Worker properties are as follwos: > >> ... worker.list=testAPJ > >> worker.testAPJ.port=8009 worker.testAPJ.host=127.0.0.1 >> worker.testAPJ.type=ajp13 worker.testAPJ.socket_keepalive=1 >> worker.testAJP.connection_pool_timeout=600 ... > >> At that point Apache seems to be stuck/struggling (but our tomcat >> does not seem to be under pressure). Restarting Apache solves the >> issue ... till it pops up again ... > >> What is happening? What needs tob e tuned? > >> Apache 2.4.34, tried both event- and worker-MPM > > How many httpd nodes? Which MPM? Per MPM, what is MaxClients, etc.? > > How many Tomcat nodes? Tomcat connector configuration? > > Usually, this happens because you are overwhelming your Tomcat nodes > with connections from the web server. Remember that every Tomcat node > needs to be able to handle the maximum number connections from *all > web servers simultaneously*. That number is probably way more than > your Tomcat connector is configured to handle. > > -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 > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluf8/sACgkQHPApP6U8 pFh5Dw/+KPqqu13CiyyjvZ
AW: jk_handler::mod_jk.c (2917): Could not get endpoint for worker ...
>How many httpd nodes? 1 >Which MPM? Tried worker and event >Per MPM, what is MaxClients, etc.? Listen 80 Listen 443 ServerRoot "/usr/local/apache2" ServerName localhost:80 PidFile logs/httpd.pid Timeout 10 UseCanonicalName Off KeepAlive On ServerTokens Prod MaxKeepAliveRequests 100 KeepAliveTimeout 1 TraceEnable off HostnameLookups Off ServerSignature Off ServerLimit16 MaxRequestWorkers 512 ThreadLimit32 ThreadsPerChild32 MaxConnectionsPerChild 0 >How many Tomcat nodes? 1 >Tomcat connector configuration? Thx for any advice - Clemens -Ursprüngliche Nachricht- Von: Christopher Schultz Gesendet: Sonntag, 16. September 2018 20:42 An: users@tomcat.apache.org Betreff: Re: jk_handler::mod_jk.c (2917): Could not get endpoint for worker ... -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 9/15/18 06:50, Clemens Wyss DEV wrote: > Hi all, we are seeing quite a few: "[Mon Sep 10 15:19:46 2018] > [27562:140532026529536] [error] jk_handler::mod_jk.c (2917): Could not > get endpoint for worker=testAPJ" > > errors in our md_jk.log. Worker properties are as follwos: > > ... worker.list=testAPJ > > worker.testAPJ.port=8009 worker.testAPJ.host=127.0.0.1 > worker.testAPJ.type=ajp13 worker.testAPJ.socket_keepalive=1 > worker.testAJP.connection_pool_timeout=600 ... > > At that point Apache seems to be stuck/struggling (but our tomcat does > not seem to be under pressure). Restarting Apache solves the issue ... > till it pops up again ... > > What is happening? What needs tob e tuned? > > Apache 2.4.34, tried both event- and worker-MPM How many httpd nodes? Which MPM? Per MPM, what is MaxClients, etc.? How many Tomcat nodes? Tomcat connector configuration? Usually, this happens because you are overwhelming your Tomcat nodes with connections from the web server. Remember that every Tomcat node needs to be able to handle the maximum number connections from *all web servers simultaneously*. That number is probably way more than your Tomcat connector is configured to handle. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlueo+oACgkQHPApP6U8 pFhwVw/+M48YAmMzOBmHelQyzyFQFOZj5hEy/bUVyDmTgJ6xWfiRxSgJRViRK6lW DxAs1YFdLdam/RZg9uraE/KKc01zAtNKPAbr134Vkz4/gVMbCs1Ndc1rlvb2Etjb dOX7JajPOgLZa8m0hIu4KitkhbkXBJmqT2zQOmLF1KZmyNmaxkgknQux3K5mn5P9 p/ml2N9FTaxh1PYVnQWPKbLlwBBRlxHrTMqeLLpy5rZh8x41sSCdNQI2eLOopWAZ 1bRkOFMMCdT66yp5VcPTMNCKBL98GWsewTsRhkO5EB54IoL/x/uIYkx7BuHpU/C4 lt9dSYECqzp1HZJBkJKAUxsGRCH2hcTQJ75g+X4QfhCFv6ZKQTy+j8cE6nvwXk5D T9krmy9flmKccmFq+EPwt8mIcC0aZQ9TRmCBW5+HRQh/LTf4BexA0pDq4Yi2zxc2 9PkZSaTGkFLUGpLDH5qIwNhH78LhHT1BjwWxkeupgLAscEIb1znjZhwiJ87zd/7/ HHKXttaIUJ2E4s1zptkg1m8dNuLS7GCv/GuO1TER2Nk/4BtIrHE1QojNZj0Logll B65vvtHS7UdIarfF1DU1Jq7mh+fJ7PZseFgPI2WukwhUndNqo+AZ8ipnJEEAKklS hxsPGW0vuRzyqXV0IHB7rQMwAEArnq8yEi0Mwj7WagPQmKrxDdE= =7/Kx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
jk_handler::mod_jk.c (2917): Could not get endpoint for worker ...
Hi all, we are seeing quite a few: "[Mon Sep 10 15:19:46 2018] [27562:140532026529536] [error] jk_handler::mod_jk.c (2917): Could not get endpoint for worker=testAPJ" errors in our md_jk.log. Worker properties are as follwos: ... worker.list=testAPJ worker.testAPJ.port=8009 worker.testAPJ.host=127.0.0.1 worker.testAPJ.type=ajp13 worker.testAPJ.socket_keepalive=1 worker.testAJP.connection_pool_timeout=600 ... At that point Apache seems to be stuck/struggling (but our tomcat does not seem to be under pressure). Restarting Apache solves the issue ... till it pops up again ... What is happening? What needs tob e tuned? Apache 2.4.34, tried both event- and worker-MPM Thx in advance Clemens
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
>you;d expect such threads to be started and stopped by a ServletContextListener I guess the ServletContextListener is being called/executed from/by another thread than the startStop-thread (and hence has another classloader)? -Ursprüngliche Nachricht- Von: Clemens Wyss DEV <clemens...@mysign.ch> Gesendet: Dienstag, 6. März 2018 07:51 An: 'Tomcat Users List' <users@tomcat.apache.org> Betreff: AW: Blocked Tomcat while (due to?) "concurrent class loading"? >The full thread dump when the problem occurs would be helpful. Note that the >thread dump should tell you if there is a deadlock. If there is no deadlock >but you have a thread stuck at the point above that looks very much like a JVM >bug. The stacktraces indicate no deadlock, nevertheless the JVM is "blocked". Should I attach or copy a stacktrace? > you;d expect such threads to be started and stopped by a > ServletContextListener. Thx, we'll do this -Ursprüngliche Nachricht- Von: Mark Thomas <ma...@apache.org> Gesendet: Montag, 5. März 2018 14:28 An: users@tomcat.apache.org Betreff: Re: Blocked Tomcat while (due to?) "concurrent class loading"? On 03/03/18 16:56, Clemens Wyss DEV wrote: > From time to time we encouter tomcats which block while starting up. The > stacktraces of the then "running" (but effectively blocked) threads (one of > them being the init servlet starting thread) look alike: > ajp-nio-8059-exec-8 > Stack Trace is: > java.lang.Thread.State: RUNNABLE > at java.lang.Class.forName0(Native Method) <-- STAYS HERE FOREVER at > java.lang.Class.forName(Class.java:264) > at > ch.mysign.cms.commons.ReflectUtil.getClassForClassName(ReflectUtil.jav > a:76) at > ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) > at > ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTableC > onfig.java:82) at > sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > orImpl.java:43) > ... > > i.e. there seems to be class loading ongoing. Unfortunately I cannot provide > code that reproduces this (mis)behavior/bug. > I can say though that the -XX:+AlwaysLockClassLoader JVM option "helps". > > Question 1: > what happens if the init servlet spawns a thread and by coincidence (timing > issue?) at the "very same time" the init servlet thread and the spawned > thread try to load a (possibly even the same?) class? Can't happen. Locking in the class loader ensures that one thread will load the class while the other thread waits. Then both will continue. > Question 2: > is spawning a thread in the initservlet "allowed" at all? It is allowed but it is 'odd'. Normally, you;d expect such threads to be started and stopped by a ServletContextListener. > Context/environment: > Debian Stretch > JDK 1.8.0_162 > Tomcat 8.5.28 > > To be noted: weh ad this "issue" with/in other environments too (even on > Win10) ... > > Sorry for being so "fuzzy" but that's all we have to tell > > We can live for the moment with the AlwaysLockClassLoader-flag, but > nevertheless would like to know if this is a bug or if we are doing something > wrong ... Feels like a JVM issue. You can try using the non-parallel class loader: https://tomcat.apache.org/tomcat-8.5-doc/config/loader.html The full thread dump when the problem occurs would be helpful. Note that the thread dump should tell you if there is a deadlock. If there is no deadlock but you have a thread stuck at the point above that looks very much like a JVM bug. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
>The full thread dump when the problem occurs would be helpful. Note that the >thread dump should tell you if there is a deadlock. If there is no deadlock >but you have a thread stuck at the point above that looks very much like a JVM >bug. The stacktraces indicate no deadlock, nevertheless the JVM is "blocked". Should I attach or copy a stacktrace? > you;d expect such threads to be started and stopped by a > ServletContextListener. Thx, we'll do this -Ursprüngliche Nachricht- Von: Mark Thomas <ma...@apache.org> Gesendet: Montag, 5. März 2018 14:28 An: users@tomcat.apache.org Betreff: Re: Blocked Tomcat while (due to?) "concurrent class loading"? On 03/03/18 16:56, Clemens Wyss DEV wrote: > From time to time we encouter tomcats which block while starting up. The > stacktraces of the then "running" (but effectively blocked) threads (one of > them being the init servlet starting thread) look alike: > ajp-nio-8059-exec-8 > Stack Trace is: > java.lang.Thread.State: RUNNABLE > at java.lang.Class.forName0(Native Method) <-- STAYS HERE FOREVER at > java.lang.Class.forName(Class.java:264) > at > ch.mysign.cms.commons.ReflectUtil.getClassForClassName(ReflectUtil.jav > a:76) at > ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) > at > ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTableC > onfig.java:82) at > sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > orImpl.java:43) > ... > > i.e. there seems to be class loading ongoing. Unfortunately I cannot provide > code that reproduces this (mis)behavior/bug. > I can say though that the -XX:+AlwaysLockClassLoader JVM option "helps". > > Question 1: > what happens if the init servlet spawns a thread and by coincidence (timing > issue?) at the "very same time" the init servlet thread and the spawned > thread try to load a (possibly even the same?) class? Can't happen. Locking in the class loader ensures that one thread will load the class while the other thread waits. Then both will continue. > Question 2: > is spawning a thread in the initservlet "allowed" at all? It is allowed but it is 'odd'. Normally, you;d expect such threads to be started and stopped by a ServletContextListener. > Context/environment: > Debian Stretch > JDK 1.8.0_162 > Tomcat 8.5.28 > > To be noted: weh ad this "issue" with/in other environments too (even on > Win10) ... > > Sorry for being so "fuzzy" but that's all we have to tell > > We can live for the moment with the AlwaysLockClassLoader-flag, but > nevertheless would like to know if this is a bug or if we are doing something > wrong ... Feels like a JVM issue. You can try using the non-parallel class loader: https://tomcat.apache.org/tomcat-8.5-doc/config/loader.html The full thread dump when the problem occurs would be helpful. Note that the thread dump should tell you if there is a deadlock. If there is no deadlock but you have a thread stuck at the point above that looks very much like a JVM bug. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
>What about the storage-mechanism? Maybe you have something like an NFS share >storing the JAR file and you have a problem with the network connection? no NFS in use. Ext4 only -Ursprüngliche Nachricht- Von: Christopher Schultz <ch...@christopherschultz.net> Gesendet: Montag, 5. März 2018 20:26 An: users@tomcat.apache.org Betreff: Re: Blocked Tomcat while (due to?) "concurrent class loading"? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/5/18 8:27 AM, Mark Thomas wrote: > On 03/03/18 16:56, Clemens Wyss DEV wrote: >> From time to time we encouter tomcats which block while starting up. >> The stacktraces of the then "running" (but effectively >> blocked) threads (one of them being the init servlet starting >> thread) look alike: ajp-nio-8059-exec-8 Stack Trace is: >> java.lang.Thread.State: RUNNABLE at >> java.lang.Class.forName0(Native Method) <-- STAYS HERE FOREVER at >> java.lang.Class.forName(Class.java:264) at >> ch.mysign.cms.commons.ReflectUtil.getClassForClassName(ReflectUtil.ja va:76) >> >> at ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) >> at >> ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTable Config.java:82) >> >> at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) >> >> ... >> >> i.e. there seems to be class loading ongoing. Unfortunately I cannot >> provide code that reproduces this (mis)behavior/bug. I can say though >> that the -XX:+AlwaysLockClassLoader JVM option "helps". >> >> Question 1: what happens if the init servlet spawns a thread and by >> coincidence (timing issue?) at the "very same time" the init servlet >> thread and the spawned thread try to load a (possibly even the same?) >> class? > > Can't happen. Locking in the class loader ensures that one thread will > load the class while the other thread waits. Then both will continue. > >> Question 2: is spawning a thread in the initservlet "allowed" at all? > > It is allowed but it is 'odd'. Normally, you;d expect such threads to > be started and stopped by a ServletContextListener. > >> Context/environment: Debian Stretch JDK 1.8.0_162 Tomcat 8.5.28 >> >> To be noted: weh ad this "issue" with/in other environments too (even >> on Win10) ... >> >> Sorry for being so "fuzzy" but that's all we have to tell >> >> We can live for the moment with the AlwaysLockClassLoader-flag, but >> nevertheless would like to know if this is a bug or if we are doing >> something wrong ... > > Feels like a JVM issue. You can try using the non-parallel class > loader: > https://tomcat.apache.org/tomcat-8.5-doc/config/loader.html > > The full thread dump when the problem occurs would be helpful. Note > that the thread dump should tell you if there is a deadlock. If there > is no deadlock but you have a thread stuck at the point above that > looks very much like a JVM bug. What about the storage-mechanism? Maybe you have something like an NFS share storing the JAR file and you have a problem with the network connection? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqdmc4dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgKHBAAlBA+C4b0NAHO5fdR Qc/ihDxfM2E/AfuCwX3s/i/MyqlsOANSD1dn37OWStG38InasDMNetKp4+AYm3PI o8eK1LeF8qMX0b/pilGY8BiWTtvYnV+0+vUwW8fQ6FZeiJMyyA+fiuLnvvOHM8j5 cYVBsJBOkp1BrRg+ILpBfOjjLqldMpAg1C3MOwScZUdB0E0tYF5BkCNXUUcxwl+8 3VhUYIttBbYBYoU2I4dqxTD24wb+sIKLGdLpsxvI8CzworRiAT/gYPMnaU2m5hgJ E1cRbkTXohgX4IweYAJQfITHXAE9hoMBtvOxuSqRUuNM7CD8yItfOEt5LyixSN38 QGxgV98PgW+mUlgsRNBCZaki74cUuxvbGmH6mylx8iDNj8sFUMhvgh6bkYeJzgek J73iYM/KJOsPFTRqryQtiqxH8eik7shjjyd9/p2lfTy9dzFct4T+Raz8l7K3M5tK nKpeFq2BEVJhHTU7pcHJLlybl5olDWO5h3t5e9/SvUonGPnRpsPuBxmv1E5b/kki gDMdZKtIJQ2VULueN+mriIMtY2qN5tBEY+AygvK150qxeoVZrh+ZLkYCRX0qficy D1fQiyAtK3FeUCedSpVlte1AXQIFdnQAXdU6UXT1B+NYRtUndrW+KQjekkDrkPNi oe9krB2/pZ6R3D2GZ2nCjcyOyFU= =zAaE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Blocked Tomcat while (due to?) "concurrent class loading"?
From time to time we encouter tomcats which block while starting up. The stacktraces of the then "running" (but effectively blocked) threads (one of them being the init servlet starting thread) look alike: ajp-nio-8059-exec-8 Stack Trace is: java.lang.Thread.State: RUNNABLE at java.lang.Class.forName0(Native Method) <-- STAYS HERE FOREVER at java.lang.Class.forName(Class.java:264) at ch.mysign.cms.commons.ReflectUtil.getClassForClassName(ReflectUtil.java:76) at ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) at ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTableConfig.java:82) at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ... i.e. there seems to be class loading ongoing. Unfortunately I cannot provide code that reproduces this (mis)behavior/bug. I can say though that the -XX:+AlwaysLockClassLoader JVM option "helps". Question 1: what happens if the init servlet spawns a thread and by coincidence (timing issue?) at the "very same time" the init servlet thread and the spawned thread try to load a (possibly even the same?) class? Question 2: is spawning a thread in the initservlet "allowed" at all? Context/environment: Debian Stretch JDK 1.8.0_162 Tomcat 8.5.28 To be noted: weh ad this "issue" with/in other environments too (even on Win10) ... Sorry for being so "fuzzy" but that's all we have to tell We can live for the moment with the AlwaysLockClassLoader-flag, but nevertheless would like to know if this is a bug or if we are doing something wrong ... Thx in advance! -Clemens
AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
If you are starting a new thread to generate a PDF yes we do but blocking the request-processing thread waiting for it to complete no we don't Okay, so this is your error handler checking the value of request.getRemoteAddr() and throwing an error because the IP address is not valid for that URL, right? true and the container (Tomcat) assumes that the web application is not playing games with the request, response, etc. at most getting stuff from the request (which we expect(ed) to be immutable) that can corrupt your requests (and responses) at best and be a severe security vulnerability at worst AGAIN we were not aware of Tomcat re-uses Request and Response objects to reduce the amount of heap-thrashing that would otherwise occur which is officially broken if it relies on request or response objects outliving the time during which the request-processing thread has been allocated to a particular request Reading the spec http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html only athenticate and getSession are explicitly meant to not be called after a response has been commited. Where do I find the sepcification you mention? Regards Clemens -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Donnerstag, 13. März 2014 16:00 An: Tomcat Users List Betreff: Re: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/13/14, 3:24 AM, Clemens Wyss DEV wrote: Dear Christopher, But you also don't know what you are doing If you don't help us again I appreciate your help and you definitely know more about tomcat than I do. IMHO, I do help and I try to focus on what is relevant. It doesn't make sense to put our million lines-of-code and log entries online, does it? No. But instead, you might be able to copy/paste like 10 lines of the log that shows what you are talking about. Follows an example of what we see: access.log (apache) ... [1] 66.249.78.105 !! hostname !! - [13/Mar/2014:07:21:03 +0100] GET /de/dialog-product-pdf.html?productGroupId=220 HTTP/1.1 200 256 - Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) - [2] 212.243.6.186 !! hostname !! - [13/Mar/2014:07:21:04 +0100] GET /myinterfaces/webstatus/webstatus.xml HTTP/1.1 404 27851 - Jakarta Commons-HttpClient/3.1 $Version=0; JSESSIONID=E405CB1E766D20B4C0CE82106797ED3D; $Path=/ ... [1] 66.249.78.105 (google bot) is accessing /de/dialog-product-pdf.html?productGroupId=220 [2] 212.243.6.186 (our monitoring app/site) is accessing /myinterfaces/webstatus/webstatus.xml Okay, everything looks good so far. app.log (tomcat, servlet) ... [1] 2014-03-13 07:21:04,155 ajp-bio-8069-exec-9 WARN ch.mysign.cms.customized.CmsErrorHandler - HTTP error code '404' thrown for request '/myinterfaces/webstatus/webstatus.xml'. Message: Page not found! remote IP: '66.249.78.105', IP-RegExp: '!! Regex of IPs allowed !!' Okay, so this is your error handler checking the value of request.getRemoteAddr() and throwing an error because the IP address is not valid for that URL, right? What code is generating this log message? Does Velocity have anything to do with it? It's probably a red herring, honestly. Would it be possible to get a stack trace of the place where you detect the error? That would help figure out if there is a component where a problem might occur. How are you connecting httpd to Tomcat? What version of whatever are you using? Does this help? Yes. For instance, you never mentioned that you were using Apache httpd in front of Tomcat before. We DO NOT manipulate any request-object (no setters, are there ;)) and we DO NOT share a request-object accross requests. Worst that could (and does) happen is a request-object (in a velocitycontext) could be accessed for as long as a few minutes IF we spawn out a thread to handle a long running process ... rendering a pdf or alike. You need to stop doing this. If you want to service a long-lived request and allow the request-processing thread to go back into thread pool, you must use a formal async API or Bad Things will happen. The spec requires that a single thread handle the entire request when not using async, and the container (Tomcat) assumes that the web application is not playing games with the request, response, etc. objects that are bound to the request. If you are starting a new thread to generate a PDF but blocking the request-processing thread waiting for it to complete, then you are wasting time and resources with the second thread. If I understand you correctly, you are making a mistake that can corrupt your requests (and responses) at best and be a severe security vulnerability at worst. What is(was) definitely new to me is the fact that the HttpServletRequest-objects handed into the servlet are not immutable snapshots
AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
Dear Christopher, But you also don't know what you are doing If you don't help us again I appreciate your help and you definitely know more about tomcat than I do. IMHO, I do help and I try to focus on what is relevant. It doesn't make sense to put our million lines-of-code and log entries online, does it? What remains is describing in detail what we are doing. If I had a minimal example to show I would... Follows an example of what we see: access.log (apache) ... [1] 66.249.78.105 !! hostname !! - [13/Mar/2014:07:21:03 +0100] GET /de/dialog-product-pdf.html?productGroupId=220 HTTP/1.1 200 256 - Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) - [2] 212.243.6.186 !! hostname !! - [13/Mar/2014:07:21:04 +0100] GET /myinterfaces/webstatus/webstatus.xml HTTP/1.1 404 27851 - Jakarta Commons-HttpClient/3.1 $Version=0; JSESSIONID=E405CB1E766D20B4C0CE82106797ED3D; $Path=/ ... [1] 66.249.78.105 (google bot) is accessing /de/dialog-product-pdf.html?productGroupId=220 [2] 212.243.6.186 (our monitoring app/site) is accessing /myinterfaces/webstatus/webstatus.xml app.log (tomcat, servlet) ... [1] 2014-03-13 07:21:04,155ajp-bio-8069-exec-9 WARN ch.mysign.cms.customized.CmsErrorHandler - HTTP error code '404' thrown for request '/myinterfaces/webstatus/webstatus.xml'. Message: Page not found! remote IP: '66.249.78.105', IP-RegExp: '!! Regex of IPs allowed !!' ... [1] handling /myinterfaces/webstatus/webstatus.xml we see/get remote address 66.249.78.105 which is not allowed to access this page [and yes I know that IP filtering could be done @apache, BUT for certain situations we do this within tomcat] Does this help? We DO NOT manipulate any request-object (no setters, are there ;)) and we DO NOT share a request-object accross requests. Worst that could (and does) happen is a request-object (in a velocitycontext) could be accessed for as long as a few minutes IF we spawn out a thread to handle a long running process ... rendering a pdf or alike. What is(was) definitely new to me is the fact that the HttpServletRequest-objects handed into the servlet are not immutable snapshots of the point of entrance. Or am I wrong here too? Thx Clemens
AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
VelocityViewServlet or VelocityLayoutServlet? None of these in use I give my szenario another try ;) [HTTP REQUEST 1] enters [HTTP REQUEST 1] starts writing to the response.writer - at a certain buffer limit the response is commited [HTTP REQUEST 2] enters, gets the same (i.e. the recycled) Request as REQUEST 1 [HTTP REQUEST 1] while still writing (renderig velocity template) request.getRemoteAddress() is being called [HTTP REQUEST 2] calls request.getRemoteAddress() === what address am I getting? -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Dienstag, 11. März 2014 19:47 An: Tomcat Users List Betreff: Re: AW: request.getRemoteAddr() sometimes returning IP address from the previous request -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/11/14, 11:23 AM, Clemens Wyss DEV wrote: First of all: thanks for the quick replies! I appreciate very much. It would help if you told us which Tomcat version you were using. Tomcat 7.0.52, i.e. latest greatest (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? Define what you mean by volatile. the members of the request object that are recycled. To be honest, I have not yet looked into the tomcat sources. To render we use velocity. The output is directly rendered into the response-writer. So the first byte written/rendered by velocity sets the response to commited (right?). Not unless you have disabled all buffering. Are you using any of the Velocity Tools stuff, like VelocityViewServlet or VelocityLayoutServlet? AND yes we have templates which we access the request#getRemoteAddress (somewhere close the end). It should not matter. As long as you aren't storing the result of request.remoteAddress anywhere, Velocity won't cache it anywhere. So could it be that these accesses set the remoteAddress tot he caller oft he previous request? This shouldn't happen. But if you play games with storing request objects in various places, you could have a problem. This is why I asked about using VelocityViewServlet. Did you roll your own Velocity servlet? If so, you may have made a mistake building your VelocityContext which ends up using the wrong request object. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTH1okAAoJEBzwKT+lPKRYXWYP+wcp8HQHyD7Wpcmq71JB4KPO S8ivvxpku2NeRcY5v4s5CSfJ6zBbxaL8SYnSL+3nakECxIIUl0GrMZ6dGgVHS7/l cYXhMNtXe7v5mEMJpo/koMA8lajkLtD3wTTKnaJCNkEbH00pEf6mySHxLIAocJ8G IAMVTJXxJPHsuZEJr219o+OJ8j5xLbX1GQq1B27eo1eszIO09YgVrUfAzMwaCesy 3kysGiuWS52/2jvHWAm/nKwdSf+PqWX+6P6fCo7ofVdsPO0PMh+20D8eYRQIRfW2 uJGypEofH9APlWebjZrnEV8+tjUXkcK0J6CuFuvhzAwaxg3TUrOC/BjysxKulMH6 SR9E2cJZjXNB6L3gOXXX7KrFsZVElFI+jJ2HwW8yZBWCmRXnchZBwCuRJZFYOidw N7Pmu8QtdwTIU+7iL5nM9zsUJvddVlIvzgTA7lLHVFk6QteiY4ZwqZAHMOGcpEVQ LkKpUK4SB1QyIZjDtU1HpPFtD4bJKptPEKddTZZ9hJYs6nnWBouCs9XB5Y2zEYUs zK2A+jjIMfqoxJBDfQllHmw4w7uDn6/cH3tp/3uRgEDDlFf326GwgufWw4l2WBN2 NAYJERfKPiYUuz2UC3MKnabuHi2J2vySyHA7jcjLnjMqs/x/+cEihBZ6QCO9LbPM aYpgGu3bs8+BYbfgNErI =k6ip -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
(The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? No, just set the system property as per the docs. What ist he (performance) impact of setting this property to true? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request
Do you have any proof of this or is this just guess work? No guessing. Am taking into account apache's access-log and our application logging. We log the IP (i.e. request#getRemoteAddress) of sepcific requests into our application logs and from time to time see the IP oft he previous request (access.log tells us that this is the IP of the/a previous request) -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Mittwoch, 12. März 2014 13:38 An: Tomcat Users List Betreff: Re: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/2014 06:19, Clemens Wyss DEV wrote: VelocityViewServlet or VelocityLayoutServlet? None of these in use I give my szenario another try ;) [HTTP REQUEST 1] enters [HTTP REQUEST 1] starts writing to the response.writer - at a certain buffer limit the response is commited [HTTP REQUEST 2] enters, gets the same (i.e. the recycled) Request as REQUEST 1 Do you have any proof of this or is this just guess work? [HTTP REQUEST 1] while still writing (renderig velocity template) request.getRemoteAddress() is being called [HTTP REQUEST 2] calls request.getRemoteAddress() === what address am I getting? Undefined. It might be the correct answer for request 1, it might be the correct answer for request 2 or it might be garbage. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIFUeAAoJEBDAHFovYFnnrgoP/i6+PmjPsykx1uT2nF4JVbIn pQ6MDaq7j1KS3MDbecD3HCDMEc2cMDCf4A2WCzRqOl2cLt9zrU9ZR0vFn+fR8uxu bw7p5QvuGGIHG38871260Wfj6TIDuI6U+Aoec6F9YfKbYyrBNGXHodInZV7p4eoE B3Mjz87zfcNeHPTy0u8ihUxEPb/DGAAXCb1S6UsDxh9NadHa+ZKm5A98Dvt0z2v8 /Th8TXeKETm1iTV39vP8gWloYEud8LTFCFBagFRnGCBq5jon0q5jcVTRXcQB6+9r cCBNokB1PeBuejB+EMhuQfWCLPq5hio/ZxomQfBOYXPkgf/8JFCeqOHTg791r37k /kvshmZAqZkH+BYCV+0stve1Z9lV6cst1qWT79PKynv/9liVAi2U5l3X79G4QpvK RbvJ+K5z/m6EZ87H/zsRykoraPEGfR8kwxIpsoHWEDbuTMmcNO2A9hpBQz4ngE2u OPF3hq5lYFvyKU9a3BfqWJN6M0khYXKDFtxshqpIpUL4hoJSJEr1kpyr7rrNEakz ysxHJybGKvxpzgE1TWtbGc8tZKfA06hCbghLXhCd/yf/yiS26wTQ8JLpHk5C60DG c+7HRFCvqmojF0/cN7TbKWWvdtYInk8eaWxGbT5O+JM++xMStZf3j8SNGRTCVTWP 2uIiTY7313P6df1X6qMK =kgoB -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
AW: request.getRemoteAddr() sometimes returning IP address from the previous request
By all means, post the relevant portion of the log file. I don't think this is of big help here. It would be very helpful if you'd answer my earlier question about how you take a request and route it to Velocity We put the request into the velocityContext and hence have the possibility to access whe(r|n)ever needed How do you know that the requests are coming from certain IPs and they are then being reported incorrectly in the access.log or in your own web pages. 1) in the access.log we see all requests 2) if a specific monitoring-URL is called from our monitoring site (which's IP we know ;) ), AND the IP does not match the monitoring site, we write out the remote IP into the app-log as an error Now if the load on our site is high (bots accessing) then we frm time to time see these errors AND in the access.log we see that reported IP matches the request before the monitoring request (from the bot) Hope this helps -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 12. März 2014 17:41 An: Tomcat Users List Betreff: Re: AW: AW: AW: request.getRemoteAddr() sometimes returning IP address from the previous request -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Clemens, On 3/12/14, 11:34 AM, Clemens Wyss DEV wrote: Do you have any proof of this or is this just guess work? No guessing. Am taking into account apache's access-log and our application logging. We log the IP (i.e. request#getRemoteAddress) of sepcific requests into our application logs and from time to time see the IP oft he previous request (access.log tells us that this is the IP of the/a previous request) By all means, post the relevant portion of the log file. How do you know that the requests are coming from certain IPs and they are then being reported incorrectly in the access.log or in your own web pages. It would be very helpful if you'd answer my earlier question about how you take a request and route it to Velocity. You may be making serious mistakes when you do that which could be the root cause of these problems. You are unlikely to be able to break the access log, even if you break your own application. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTII4lAAoJEBzwKT+lPKRYYskP/0K/mo6m/TOu5UmfmKAeoIMV uuuNgQSFms8c/ufad+b/kywDt//TcPuu9fUsOMJmFuoMEoK4iI+xKTTApb/fuii5 yA2p8XD/qnRM227RSoquITn9WCsiTLfW9Eu/Hm5/VP9lPJ46yKX3QiEiz2xXPtZh rp5nD22QTulmX+WrNiAPXPd1Z+Dq4xQ8Uto/AU8TUGzjrl7J8IfftAbObYQyqtSo hdlB+gdYY/hvY/WifqmpHHd9eUv7ANzHTa3cKGPmWC6qR42XEaLL8qi5bcnfBPzr onRfANCBq1Qr70xA0P2l02ZQ1WpXIvEgOhkz+M5aQr0myC7MBnTUoymzXXZdkFwo R2Xcj1wC2byHstWlxWIm1ieGrH60iR+krYVNog8JUJ3WCLR3NYCaX2dM/ZGB2dk7 FhpK2OulLKNQUq9WMVEgoTUeGiuxWzurrIXriarQDKPoajjCm2Bw3+ODtC9jxy8H AVFb03E60pdUGDBxq0HOr8A4N9v4sYlbWz69b3lbv5jFlqVKfd4n06sK5hOxxcUE jxQd26m/XwaQ0cYV93r0fb7ygoPxHwmDuK7OC1QuciCraqpbkE94CHuKmIHzD/p4 oz2rf2JVdRWszr+s8HQ6KnyB7uN7D5mnxTZhXJTTGsc3BV+38nA+gLDRHY6yFHIN BcDnVbvH25WtcYxsHsJV =ungh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
request.getRemoteAddr() sometimes returning IP address from the previous request
Hi all, we are still facing this issue here https://issues.apache.org/bugzilla/show_bug.cgi as Mark Thomas points out https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16 the bug is fixed. Trying to find out what we are doing wrong I have the following questions: 1) as soon as a response is commited we should no longer access the corresponding request? 2) a response is commited (at latest) as soon as a byte is written into the response's writer? 3) which members of the request are volatile? Are these specified in the ServletRequest API? Thx Clemens - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: request.getRemoteAddr() sometimes returning IP address from the previous request
First of all: thanks for the quick replies! I appreciate very much. It would help if you told us which Tomcat version you were using. Tomcat 7.0.52, i.e. latest greatest (The reuse can be disabled via a system property, see RECYCLE_FACADES. I usually do so, for better security) Would I need to compile my own tomcat? Define what you mean by volatile. the members of the request object that are recycled. To be honest, I have not yet looked into the tomcat sources. To render we use velocity. The output is directly rendered into the response-writer. So the first byte written/rendered by velocity sets the response to commited (right?). AND yes we have templates which we access the request#getRemoteAddress (somewhere close the end). So could it be that these accesses set the remoteAddress tot he caller oft he previous request? Thx Clemens -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Dienstag, 11. März 2014 15:34 An: Tomcat Users List Betreff: Re: request.getRemoteAddr() sometimes returning IP address from the previous request On 11/03/2014 14:16, Clemens Wyss DEV wrote: Hi all, we are still facing this issue here https://issues.apache.org/bugzilla/show_bug.cgi as Mark Thomas points out https://issues.apache.org/bugzilla/show_bug.cgi?id=51872#c16 the bug is fixed. Trying to find out what we are doing wrong I have the following questions: 1) as soon as a response is commited we should no longer access the corresponding request? There are no such restrictions. 2) a response is commited (at latest) as soon as a byte is written into the response's writer? A response is committed when the first byte is sent to the client. 3) which members of the request are volatile? Are these specified in the ServletRequest API? Define what you mean by volatile. The typical causes of this type of issue is retaining a reference to a request and/or response (in a filter, in a session or similar) and then trying to use the request or response object when processing a different request/response pair. It would help if you told us which Tomcat version you were using. 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
