AW: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
Interesting. If the problem was too many sockets in CLOSE_WAIT, consider looking at the connectionLinger setting on your AJP connector's in Tomcat. Mark Mhh.. I haven't heard about the options before.. But it sound like a great idea.. Default is -1. So what would be a good time, one minute? Thanks Mit freundlichen Grüßen David Kumar Softwareentwickler, B. Sc. Abteilung Infotech - Interaktiv TELESTAR-DIGITAL GmbH Am Weiher 14 D-56766 Ulmen http://www.telestar.de/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
sry I was wrong default is -1 what menas it is disabled, so I'm fine..?!? Interesting. If the problem was too many sockets in CLOSE_WAIT, consider looking at the connectionLinger setting on your AJP connector's in Tomcat. Mark Mhh.. I haven't heard about the options before.. But it sound like a great idea.. Default is -1. So what would be a good time, one minute? Thanks Mit freundlichen Grüßen David Kumar Softwareentwickler, B. Sc. Abteilung Infotech - Interaktiv TELESTAR-DIGITAL GmbH Am Weiher 14 D-56766 Ulmen http://www.telestar.de/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
hey, Yes. Whether this is the java that runs tomcat is not immediately evident. But it also seems that they concern port numbers like 7009, 9009 etc. which must be your AJP Connectors, so let's assume the CLOSE-WAITs all involve Tomcat. The first observation hat I would make is that this looks like a pretty busy system. Then, there are 2100+ lines in that list. Let's assume first that they are all internal connections (which probable they are not, but for simplicity), so that there are actually 2 lines for the same connection, like these : tcp0 0 127.0.0.1:39872 127.0.0.1:7009 FIN_WAIT2 20766/apache2 . .. tcp6 1 0 127.0.0.1:7009 127.0.0.1:39872 CLOSE_WAIT 20564/java .. So let's say that we have in total about 1000 connections active in some state. Compared to that, there are 54 connections in CLOSE_WAIT, which is like 5%. That does not really sound pathological to me, considering that CLOSE_WAIT is a normal state through which any TCP connection goes at some point. If you look again at the above connection, and if I am not confusing my clients and servers again, it looks here like : - Apache http (PID 20766), as a client, has established a connection to port 7009 of the server Tomcat (PID 20564). That must be an AJP connection, from the mod_jk module of Apache, to the AJP Connector in Tomcat. - A while later, Apache closes the connection. It sends a FIN packet to Tomcat, and waits for Tomcat to acknowledge this FIN packet. - when it receives the FIN packet from Apache, Tomcat responds with an ACK, and then goes to the CLOSE_WAIT state. - when Apache receives the ACK from Tomcat, it goes to state FIN_WAIT2. (and that is the current state of the above connection) - now Tomcat is supposed to send a FIN to Apache, and receive an ACK in return. - if Apache receives the FIN from Tomcat, it sends back an ACK, and goes into state TIME_WAIT (where it doesn't expect anything anymore), and then after a short moment, it discards that connection. If there are connections that remain in the CLOSE_WAIT state for very long, it means that something in the last 2 steps above is not working. Now in your listing, we see about 1900 lines in the TIME_WAIT state, all of them *to* an AJP port of Tomcat. This seems to suggest that the Apache side is working as it should. But if the Tomcat side stays in CLOSE_WAIT for a long time, then it would suggest that on the Tomcat side, that connection is never properly close()'d. But this is the request/response connection, so I doubt that there would be a bug there, otherwise we'd have problems reports filling this list every day. Might there be that there is somewhere a discrepancy between the keep-alive settings, between Apache and Tomcat ? or maybe your server is just not strong enough for the load you are putting on it ? According to vmtools the server is boring most times.. I almost totally agree, but I'm not sure if it is a AJP fault. Because most time everything is alright, so all of theses steps are done. Just sometimes after a arbitrarily amount of time ajp / tomcat runs crazy. And in my sample there is the sourceport 9009 / java. It looks for me that apache didn't received the ACK from tomcat after CLOSE_WAIT or it just don't care because apache thought this connections is already closed? Let's assume that is the case.. Isn't there a option to tell tomcat to wait max. time for a response and after that time kill the connection? As far as I understand connectionTimeout is just for the initial request, so after Apache did answer in first correctly connectionTimeout is valueless? Attached you can find our configuration files, maybe you can find a / some misconfigurations? I would agree that we have maybe a kind of misconfigured timeout problem... thanks Mit freundlichen Grüßen David Kumar Softwareentwickler, B. Sc. Abteilung Infotech - Interaktiv TELESTAR-DIGITAL GmbH Am Weiher 14 D-56766 Ulmen http://www.telestar.de/ # # Based upon the NCSA server configuration files originally by Rob McCool. # # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See http://httpd.apache.org/docs/2.2/ for detailed information about # the directives. # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # # The configuration directives are grouped into three basic sections: # 1. Directives that control the operation of the Apache server process as a # whole (the 'global environment'). # 2. Directives that define the parameters of the 'main' or 'default' server, # which responds to requests that aren't handled by a virtual host. # These directives also provide default values for the settings # of all virtual hosts. #
Re: AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
David Kumar wrote: hey, Yes. Whether this is the java that runs tomcat is not immediately evident. But it also seems that they concern port numbers like 7009, 9009 etc. which must be your AJP Connectors, so let's assume the CLOSE-WAITs all involve Tomcat. The first observation hat I would make is that this looks like a pretty busy system. Then, there are 2100+ lines in that list. Let's assume first that they are all internal connections (which probable they are not, but for simplicity), so that there are actually 2 lines for the same connection, like these : tcp0 0 127.0.0.1:39872 127.0.0.1:7009 FIN_WAIT2 20766/apache2 . .. tcp6 1 0 127.0.0.1:7009 127.0.0.1:39872 CLOSE_WAIT 20564/java .. So let's say that we have in total about 1000 connections active in some state. Compared to that, there are 54 connections in CLOSE_WAIT, which is like 5%. That does not really sound pathological to me, considering that CLOSE_WAIT is a normal state through which any TCP connection goes at some point. If you look again at the above connection, and if I am not confusing my clients and servers again, it looks here like : - Apache http (PID 20766), as a client, has established a connection to port 7009 of the server Tomcat (PID 20564). That must be an AJP connection, from the mod_jk module of Apache, to the AJP Connector in Tomcat. - A while later, Apache closes the connection. It sends a FIN packet to Tomcat, and waits for Tomcat to acknowledge this FIN packet. - when it receives the FIN packet from Apache, Tomcat responds with an ACK, and then goes to the CLOSE_WAIT state. - when Apache receives the ACK from Tomcat, it goes to state FIN_WAIT2. (and that is the current state of the above connection) - now Tomcat is supposed to send a FIN to Apache, and receive an ACK in return. - if Apache receives the FIN from Tomcat, it sends back an ACK, and goes into state TIME_WAIT (where it doesn't expect anything anymore), and then after a short moment, it discards that connection. If there are connections that remain in the CLOSE_WAIT state for very long, it means that something in the last 2 steps above is not working. Now in your listing, we see about 1900 lines in the TIME_WAIT state, all of them *to* an AJP port of Tomcat. This seems to suggest that the Apache side is working as it should. But if the Tomcat side stays in CLOSE_WAIT for a long time, then it would suggest that on the Tomcat side, that connection is never properly close()'d. But this is the request/response connection, so I doubt that there would be a bug there, otherwise we'd have problems reports filling this list every day. Might there be that there is somewhere a discrepancy between the keep-alive settings, between Apache and Tomcat ? or maybe your server is just not strong enough for the load you are putting on it ? According to vmtools the server is boring most times.. What do you mean, boring ? (like German langweilig ?). If you have 2000+ connections there in one state or another, that should mean that the system is usually pretty busy, I would think. On my production machines (vSphere VM's, Linux, Apache+Tomcat, +database), some of them pretty busy, I never see more than 200-300 connections with netstat. That is all states together, with netstat -t -pan | wc -l). Granted, I am not running Yahoo or Facebook, but still, these are public Internet servers, fairly sollicited. I almost totally agree, but I'm not sure if it is a AJP fault. Because most time everything is alright, so all of theses steps are done. Just sometimes after a arbitrarily amount of time ajp / tomcat runs crazy. And in my sample there is the sourceport 9009 / java. It looks for me that apache didn't received the ACK from tomcat after CLOSE_WAIT or it just don't care because apache thought this connections is already closed? Let's assume that is the case.. Isn't there a option to tell tomcat to wait max. time for a response and after that time kill the connection? As far as I understand connectionTimeout is just for the initial request, so after Apache did answer in first correctly connectionTimeout is valueless? Let's look at the various options in the Connector : First, the -1 in some options means unlimited or forever, it doesn't mean disabled. Second, some parameters say that if they are not specified, they default to the value of another parameter, so you should check really what this other parameter is set to. Attached you can find our configuration files, maybe you can find a / some misconfigurations? I'll have a look. I would agree that we have maybe a kind of misconfigured timeout problem... thanks Mit freundlichen Grüßen David Kumar Softwareentwickler, B. Sc. Abteilung Infotech - Interaktiv TELESTAR-DIGITAL GmbH Am Weiher 14 D-56766 Ulmen http://www.telestar.de/
AW: AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
Hey André, According to vmtools the server is boring most times.. What do you mean, boring ? (like German langweilig ?). -- Jep prety idle.. :-) If you have 2000+ connections there in one state or another, that should mean that the system is usually pretty busy, I would think. On my production machines (vSphere VM's, Linux, Apache+Tomcat, +database), some of them pretty busy, I never see more than 200-300 connections with netstat. That is all states together, with netstat -t -pan | wc -l). Granted, I am not running Yahoo or Facebook, but still, these are public Internet servers, fairly sollicited. I almost totally agree, but I'm not sure if it is a AJP fault. Because most time everything is alright, so all of theses steps are done. Just sometimes after a arbitrarily amount of time ajp / tomcat runs crazy. And in my sample there is the sourceport 9009 / java. It looks for me that apache didn't received the ACK from tomcat after CLOSE_WAIT or it just don't care because apache thought this connections is already closed? Let's assume that is the case.. Isn't there a option to tell tomcat to wait max. time for a response and after that time kill the connection? As far as I understand connectionTimeout is just for the initial request, so after Apache did answer in first correctly connectionTimeout is valueless? Let's look at the various options in the Connector : First, the -1 in some options means unlimited or forever, it doesn't mean disabled. Second, some parameters say that if they are not specified, they default to the value of another parameter, so you should check really what this other parameter is set to. According to Tomcat Configuration Reference 5.5 : connectionLinger The number of milliseconds during which the sockets used by this Connector will linger when they are closed. The default value is -1 (socket linger is disabled). According to Tomcat Configuration Reference 7.0.37 : connectionLinger The number of seconds during which the sockets used by this Connector will linger when they are closed. If not specified, the JVM default will be used. As I'm at 7.0.37 I have to figure out where an how to set linger options at the JVM. I'll have a look. thx - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
David Kumar wrote: Attached you can find our configuration files, maybe you can find a / some misconfigurations? I'll have a look. Some notes : - according to the comments in your Apache config file, you are using the worker MPM. But are you sure ? what does /usr/sbin/apache2ctl -l say ? - we are missing the contents of your /etc/apache2/workers.properties file - we are missing the JkMounts or equivalent that you are doing from Apache to Tomcat. related questions : you have 2 tomcats. Are you doing load-balancing ? or are you just sending some URLs to tomcat1 and other to tomcat2 ? Are you proxying everything to the tomcats, or is the Apache httpd front-end serving some URLs on its own ? if so, what proportion ? - how many hits per second/minute/hour (any of them, approx.) is your server handling ? - you do not have any specific timeout parameters set in your Tomcat AJP Connectors, which is basically a good thing : better to leave the defaults in place, than to start playing with settings that you do not really understand, and make things worse. But you do set one : connectionTimeout=20. Which sounds extremely high to me. Re: http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html It means that when a client connects to that Connector, a Tomcat thread will be started to handle this connection; then the thread will wait on the connection, to read the request. If the request does not appear, this thread will still wait, up to 200 seconds (more than 3 minutes !) for this request to appear, before it gives up, closes that connection, and goes back to the pool of available threads. A normal client would not do that, but a badly-intentioned client that tries to create a DOS attack on your server, will do that, just to block threads on your server until there are no more threads available. In this case, it is even worse, because other parameters are using this same value as a default, like : keepAliveTimeout. This one means that once one request has been processed by this Tomcat thread on that connection, the thread will not close this connection, but wait to see if any other request appears on that connection from the same client, within the timeout given. In this case, because it defaults to connectionTimeout, the thread will wait more than 3 minutes to see if there is another request. If the client (browser) does not send any additional request on that connection, you have a thread that is blocked doing nothing, for more than 3 minutes. In this case, the client is in reality the mod_jk module under Apache. So the settings of Apache and mod_jk will matter, and I cannot tell exactly at this point what will happen. But if this was a HTTP Connector open to the external WWW world, what would certainly heppen is that you would run out of threads in Tomcat within a couple of minutes, and your server would stop accepting new requests. Or to put this another way : if this was a HTTP connector open to the outside world, and I knew the address of your server, I could bring it down in 3 seconds, using the standard ab program that comes with Apache. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
On 12.03.2013 11:58, David Kumar wrote: We got the connection_pool_timeout from here: https://community.jboss.org/wiki/OptimalModjk12Configuration I will have a look on the other recommended options Pick a source download of mod_jk. It contains an example configuration that should work pretty well. Don't choose the minimal example config, just the normal one. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
On 14.03.2013 10:04, David Kumar wrote: Hey, thanks for note.. Attached you can find a new list. So, java is keeping these connections in close_wait. close_wait for an AJP connection seen from Tomcat means the other side - mod_jk - has closed the connection, but not Tomcat. This is often due to a shorter Timeout on the mod_jk side than on the Tomcat side. It is not a problem per se, but it is if it happens for too many connections for a too long time. I vaguely remember that you have a 10 second socket_timeout in your workers.properties. That's typically bad. Look at the example config in the source mod_jk download. It could be, that your requests in Tomcat got stuck and Tomcat still is in the state of working on the requests, therefore keeping the connection open to send back stuff finally, whereas mod_jk has already timed out. To check for that, take a couöple of threa dumps (not: heap dumps) of the running Tomcat process while the close_wait problem is visible. Check what your Tomcat threads are currently doing, e.g. are they mostly sitting idle in the thread pool or executor, or are many of them deep in your application stacks and waiting for database, locks or other stuff. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
Rainer Jung wrote: On 14.03.2013 10:04, David Kumar wrote: Hey, thanks for note.. Attached you can find a new list. So, java is keeping these connections in close_wait. close_wait for an AJP connection seen from Tomcat means the other side - mod_jk - has closed the connection, but not Tomcat. This is often due to a shorter Timeout on the mod_jk side than on the Tomcat side. It is not a problem per se, but it is if it happens for too many connections for a too long time. I vaguely remember that you have a 10 second socket_timeout in your workers.properties. That's typically bad. Look at the example config in the source mod_jk download. It could be, that your requests in Tomcat got stuck and Tomcat still is in the state of working on the requests, therefore keeping the connection open to send back stuff finally, whereas mod_jk has already timed out. To check for that, take a couöple of threa dumps (not: heap dumps) of the running Tomcat process while the close_wait problem is visible. Check what your Tomcat threads are currently doing, e.g. are they mostly sitting idle in the thread pool or executor, or are many of them deep in your application stacks and waiting for database, locks or other stuff. Hi Rainer, a question to you : In a previous post, David posted the output of netstat -t -pan. In that output, there are about 1900 connections from Apache to Tomcat's AJP connectors, in state TIME_WAIT. As far as I know, this indicates that the connection is closed from the point of view of Apache, and this TIME_WAIT should last only a few sec. maximum, and then should go away. Why does he have so many though ? I can't see anything like that on any of my servers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
Mit freundlichen Grüßen David Kumar Softwareentwickler, B. Sc. Abteilung Infotech - Interaktiv TELESTAR-DIGITAL GmbH Am Weiher 14 D-56766 Ulmen Tel.: + 49 (0) 6592 / 712 -2826 Tel.: + 49 (0) 2676 / 9520 -183 Fax: + 49 (0) 6592 / 712 -2829 http://www.telestar.de/ -Ursprüngliche Nachricht- Von: André Warnier [mailto:a...@ice-sa.com] Gesendet: Freitag, 15. März 2013 10:45 An: Tomcat Users List Betreff: Re: AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open Some notes : - according to the comments in your Apache config file, you are using the worker MPM. But are you sure ? what does /usr/sbin/apache2ctl -l say ? Compiled in modules: core.c mod_log_config.c mod_logio.c worker.c http_core.c mod_so.c - we are missing the contents of your /etc/apache2/workers.properties file Sry didn't rename properties, see attached.. - we are missing the JkMounts or equivalent that you are doing from Apache to Tomcat. Same to our default website related questions : you have 2 tomcats. Are you doing load-balancing ? or are you just sending some URLs to tomcat1 and other to tomcat2 ? We doing loadbalacning Are you proxying everything to the tomcats, or is the Apache httpd front-end serving some URLs on its own ? if so, what proportion ? Everything goes to the tomcats - how many hits per second/minute/hour (any of them, approx.) is your server handling ? according to our logs yesterday between 8pm and 9pm we had 73667 hits together on both tomcats. - you do not have any specific timeout parameters set in your Tomcat AJP Connectors, which is basically a good thing : better to leave the defaults in place, than to start playing with settings that you do not really understand, and make things worse. But you do set one : connectionTimeout=20. Which sounds extremely high to me. Re: http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html It means that when a client connects to that Connector, a Tomcat thread will be started to handle this connection; then the thread will wait on the connection, to read the request. If the request does not appear, this thread will still wait, up to 200 seconds (more than 3 minutes !) for this request to appear, before it gives up, closes that connection, and goes back to the pool of available threads. A normal client would not do that, but a badly-intentioned client that tries to create a DOS attack on your server, will do that, just to block threads on your server until there are no more threads available. In this case, it is even worse, because other parameters are using this same value as a default, like : keepAliveTimeout. This one means that once one request has been processed by this Tomcat thread on that connection, the thread will not close this connection, but wait to see if any other request appears on that connection from the same client, within the timeout given. In this case, because it defaults to connectionTimeout, the thread will wait more than 3 minutes to see if there is another request. If the client (browser) does not send any additional request on that connection, you have a thread that is blocked doing nothing, for more than 3 minutes. In this case, the client is in reality the mod_jk module under Apache. So the settings of Apache and mod_jk will matter, and I cannot tell exactly at this point what will happen. But if this was a HTTP Connector open to the external WWW world, what would certainly heppen is that you would run out of threads in Tomcat within a couple of minutes, and your server would stop accepting new requests. Or to put this another way : if this was a HTTP connector open to the outside world, and I knew the address of your server, I could bring it down in 3 seconds, using the standard ab program that comes with Apache. that is how our servers are connected together: We have another Webserver (different server) connecting to our Apache - Proxy which is loadbalacning our two tomcats. (Apache and tomcat are together at on server) I will go end reduce the timeout on both worker.properties and server.xml. What will be a value? 30 Seconds? Thanks a lot.. workers.tomcat_home=/opt/tomcat workers.java_home=/usr/lib/jvm/java-6-sun ps=/ worker.list=loadbalancer,status #//siehe https://community.jboss.org/wiki/OptimalModjk12Configuration worker.tomcatX.host=localhost worker.tomcatX.type=ajp13 worker.tomcatX.fail_on_status=404 worker.tomcatX.lbfactor=1 worker.tomcatX.ping_timeout=1000 worker.tomcatX.ping_mode=A worker.tomcatX.socket_timeout=10 worker.tomcatX.connection_pool_timeout=200 worker.tomcat1.reference=worker.tomcatX worker.tomcat1.port=7009 worker.tomcat2.reference=worker.tomcatX worker.tomcat2.port=9009 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=tomcat1,tomcat2 worker.status.type=status VirtualHost *:8080 ServerAdmin webmaster@localhost SetEnvIf User-Agent (internal dummy
AW: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
close_wait for an AJP connection seen from Tomcat means the other side - mod_jk - has closed the connection, but not Tomcat. This is often due to a shorter Timeout on the mod_jk side than on the Tomcat side. It is not a problem per se, but it is if it happens for too many connections for a too long time. I vaguely remember that you have a 10 second socket_timeout in your workers.properties. That's typically bad. Look at the example config in the source mod_jk download. I will do that. It could be, that your requests in Tomcat got stuck and Tomcat still is in the state of working on the requests, therefore keeping the connection open to send back stuff finally, whereas mod_jk has already timed out. To check for that, take a couöple of threa dumps (not: heap dumps) of the running Tomcat process while the close_wait problem is visible. Check what your Tomcat threads are currently doing, e.g. are they mostly sitting idle in the thread pool or executor, or are many of them deep in your application stacks and waiting for database, locks or other stuff. I try to, currently we have a watchdog running, checking every 2 minutes if the tomcats are available at 7009/9009 and http. If one of the tomcats are not responding it will be restarted Thanks David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
On 15.03.2013 11:47, André Warnier wrote: Rainer Jung wrote: On 14.03.2013 10:04, David Kumar wrote: Hey, thanks for note.. Attached you can find a new list. So, java is keeping these connections in close_wait. close_wait for an AJP connection seen from Tomcat means the other side - mod_jk - has closed the connection, but not Tomcat. This is often due to a shorter Timeout on the mod_jk side than on the Tomcat side. It is not a problem per se, but it is if it happens for too many connections for a too long time. I vaguely remember that you have a 10 second socket_timeout in your workers.properties. That's typically bad. Look at the example config in the source mod_jk download. It could be, that your requests in Tomcat got stuck and Tomcat still is in the state of working on the requests, therefore keeping the connection open to send back stuff finally, whereas mod_jk has already timed out. To check for that, take a couöple of threa dumps (not: heap dumps) of the running Tomcat process while the close_wait problem is visible. Check what your Tomcat threads are currently doing, e.g. are they mostly sitting idle in the thread pool or executor, or are many of them deep in your application stacks and waiting for database, locks or other stuff. Hi Rainer, a question to you : In a previous post, David posted the output of netstat -t -pan. In that output, there are about 1900 connections from Apache to Tomcat's AJP connectors, in state TIME_WAIT. As far as I know, this indicates that the connection is closed from the point of view of Apache, and this TIME_WAIT should last only a few sec. maximum, and then should go away. Why does he have so many though ? I can't see anything like that on any of my servers. TIME_WAIT is a state which means the connection is closed by both sides but the TCP stack still blocks the (server port, server ip, client port, client IP) quadruple for reuse to prevent long overdue packets of the old connection to disturb the new connection. It doesn't prevent new connections from being created nor are there still process resources on client or server being used for those connections (threds, buffers). It is just an entry in the OS TCP connection hash. The TIME_WAIT state is only used on the side of the connection that started the connection shutdown, i.e. that first send the FIN. The other side doesn't go into TIME_WAIT. If your clients typically start the connection shutdown you won't see the TIME_WAIT. Connections are kept in TIME_WAIT for seconds to about a minute depending on your OS and TCP tuning. For a service which uses a lot of new connections per second and initiates the shutdown for them itself it is not uncommon to see several hundreds to thousands of TIME_WAIT connections. If the count goes up into the range of 10.000-50.000 you could start running into inefficiencies of the TCP connection hash handling (depending on the OS). Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
On 15.03.2013 11:57, David Kumar wrote: It could be, that your requests in Tomcat got stuck and Tomcat still is in the state of working on the requests, therefore keeping the connection open to send back stuff finally, whereas mod_jk has already timed out. To check for that, take a couöple of threa dumps (not: heap dumps) of the running Tomcat process while the close_wait problem is visible. Check what your Tomcat threads are currently doing, e.g. are they mostly sitting idle in the thread pool or executor, or are many of them deep in your application stacks and waiting for database, locks or other stuff. I try to, currently we have a watchdog running, checking every 2 minutes if the tomcats are available at 7009/9009 and http. If one of the tomcats are not responding it will be restarted Please please before restarting take two thread dumps. On Linux/Unix a kill -QUIT will do that (and write the result to STDOUT, which depending on your setup likely goes to catalina.out). The QUIT signal does *not* terminate the JVM, it just quickly writes out the stacks of all threads. The interruption for the running JVM is minimal, so you can already try how this works before the process gets into the critical state. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: configuring tomcat7 with apache 2.2.22
Hello, I take care about an app that is a combination of Apache Server+php Drupal app and Apache Tomcat jsp app. Apache Server listens on the ports 80/443 and requests are reverse proxied to Apache Tomcat. Let's say that the tomcat app resides on/testca The apache server config will be ProxyRequests Off ProxyPass /testca ajp://127.0.0.1:9081/testca ProxyPassReverse /testca ajp://127.0.0.1:9081/testca Proxy /testca/WEB-INF Order Deny,Allow Deny from All /Proxy Proxy /testca Order Deny,Allow Allow from All /Proxy and check if ajp module is loaded: LoadModule proxy_ajp_module modules/mod_proxy_ajp.so In the Apache Tomcat's server.xml change ajp port to 9081 Connector port=9081 protocol=AJP/1.3 redirectPort=8443 / On WinXP there should be no problem. I personally develop on Win 7, production is Linux. Jan. Although not a newbie to building websites in html and php, and physical computing in C/C++, I'm having a dickens of a time understanding the documentation of Integrating Tomcat 7 with my existing Apache 2.2.22 on WinXP (company supplied development pc, nothing I can do about that). Can I get a bit of handholding please? I'm trying to evaluate a java servlet that requires tomcat. Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com - 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: configuring tomcat7 with apache 2.2.22
Thanks to some advice on this forum, and a lot of independent study and experimentation, I have a php app on apache (localhost:80) pulling in a database driven bar code from a IDAutomation Servlet running on tomcat (localhost:8080). Looks like this - $bcode = $row['Bar Code'] ; $beginurl = img src='http://localhost:8080/examples/servlet/LinearServlet?BARCODE=;; $endurl = BAR_HEIGHT=.5S=UPCA'; echo $beginurl . $bcode . $endurl; Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com ---Original Message--- From: Jan Vávra va...@602.cz To: Tomcat Users List users@tomcat.apache.org Subject: Re: configuring tomcat7 with apache 2.2.22 Sent: Mar 15 '13 07:43 Hello, I take care about an app that is a combination of Apache Server+php Drupal app and Apache Tomcat jsp app. Apache Server listens on the ports 80/443 and requests are reverse proxied to Apache Tomcat. Let's say that the tomcat app resides on/testca The apache server config will be ProxyRequests Off ProxyPass /testca ajp://127.0.0.1:9081/testca ProxyPassReverse /testca ajp://127.0.0.1:9081/testca Proxy /testca/WEB-INF Order Deny,Allow Deny from All /Proxy Proxy /testca Order Deny,Allow Allow from All /Proxy and check if ajp module is loaded: LoadModule proxy_ajp_module modules/mod_proxy_ajp.so In the Apache Tomcat's server.xml change ajp port to 9081 Connector port=9081 protocol=AJP/1.3 redirectPort=8443 / On WinXP there should be no problem. I personally develop on Win 7, production is Linux. Jan. Although not a newbie to building websites in html and php, and physical computing in C/C++, I'm having a dickens of a time understanding the documentation of Integrating Tomcat 7 with my existing Apache 2.2.22 on WinXP (company supplied development pc, nothing I can do about that). Can I get a bit of handholding please? I'm trying to evaluate a java servlet that requires tomcat. Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
Hey, Please please before restarting take two thread dumps. On Linux/Unix a kill -QUIT will do that (and write the result to STDOUT, which depending on your setup likely goes to catalina.out). The QUIT signal does *not* terminate the JVM, it just quickly writes out the stacks of all threads. The interruption for the running JVM is minimal, so you can already try how this works before the process gets into the critical state. great I just tried a kill -QUIT in our watchdog -- pretty fast. Next time we got our problem I will send the threaddump to you guys. thanks a lot David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6.0.35 in production maintaince
On Mar 14, 2013, at 6:00 PM, fachhoch wrote: I think one of my filters are involved in creating session , I tried in dev box calling the url called by load balancer ,and saw that a session is getting created every time its a new browser, so then I called a html file still session is being created, I use some of the filters which I cannot make changes to, so I am, wondering , If I can add something like a filter in web.xml which will bypass all other filters if url is lets say /myaap/ping.html how to bypass all other filters and serve the request ? You could, but I think you're making this more complicated than it needs to be. If the filter is creating a session, then just change the filter-mapping so that it isn't applied for this resource. In your web.xml, look for the filter-mapping tag for the filter that is starting the session then just change it so the filter ignores this resource. Having said that, if you absolutely want to create a custom filter, try the following: 1.) Implement Filter 2.) In the doFilter method, if request is a ping, handle it otherwise continue filter chain 3.) Define your filter in web.xml, make sure it's first in the filter chain Now your filter should execute first, if it's a ping request it will just handle it. If not, it'll continue down the filter chain like normal. Dan -- View this message in context: http://tomcat.10.n6.nabble.com/tomcat-6-0-35-in-production-maintaince-tp4995740p4995967.html Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: configuring tomcat7 with apache 2.2.22
In this situation are both server exposed - Apache Server and Apache Tomcat. It can work. When you use reverse proxy only the Apache Server is exposed. So configuring a ssl certificate is only done once. On client computer/network there could be allowed only the standard http port 80 and not 8080. Depends on situation ... Jan. Thanks to some advice on this forum, and a lot of independent study and experimentation, I have a php app on apache (localhost:80) pulling in a database driven bar code from a IDAutomation Servlet running on tomcat (localhost:8080). Looks like this - $bcode = $row['Bar Code'] ; $beginurl = img src='http://localhost:8080/examples/servlet/LinearServlet?BARCODE=;; $endurl = BAR_HEIGHT=.5S=UPCA'; echo $beginurl . $bcode . $endurl; Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com ---Original Message--- From: Jan Vávra va...@602.cz To: Tomcat Users List users@tomcat.apache.org Subject: Re: configyuring tomcat7 with apache 2.2.22 Sent: Mar 15 '13 07:43 Hello, I take care about an app that is a combination of Apache Server+php Drupal app and Apache Tomcat jsp app. Apache Server listens on the ports 80/443 and requests are reverse proxied to Apache Tomcat. Let's say that the tomcat app resides on/testca The apache server config will be ProxyRequests Off ProxyPass /testca ajp://127.0.0.1:9081/testca ProxyPassReverse /testca ajp://127.0.0.1:9081/testca Proxy /testca/WEB-INF Order Deny,Allow Deny from All /Proxy Proxy /testca Order Deny,Allow Allow from All /Proxy and check if ajp module is loaded: LoadModule proxy_ajp_module modules/mod_proxy_ajp.so In the Apache Tomcat's server.xml change ajp port to 9081 Connector port=9081 protocol=AJP/1.3 redirectPort=8443 / On WinXP there should be no problem. I personally develop on Win 7, production is Linux. Jan. Although not a newbie to building websites in html and php, and physical computing in C/C++, I'm having a dickens of a time understanding the documentation of Integrating Tomcat 7 with my existing Apache 2.2.22 on WinXP (company supplied development pc, nothing I can do about that). Can I get a bit of handholding please? I'm trying to evaluate a java servlet that requires tomcat. Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com - 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 - 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: Procrun and Tomcat service/OS shutdown on Windows
-Original Message- From: Harris, Jeffrey E. [mailto:jeffrey.har...@mantech.com] Sent: Thursday, March 14, 2013 4:11 PM To: Tomcat Users List Subject: RE: Procrun and Tomcat service/OS shutdown on Windows -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Thursday, March 14, 2013 4:01 PM To: Tomcat Users List Subject: Re: Procrun and Tomcat service/OS shutdown on Windows 2013/3/14 Thomas, Steve stho...@vocollect.com: Hi - Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a service (either via service.bat or the exe installer) on a Windows 7 64-bit OS, we are seeing an issue where the Windows shutdown kills Tomcat before our webapp shutdown sequence has time to execute fully. (Specifically, we just want to make sure our instance of HSQLDB shuts down correctly, otherwise corruption can ensue.) Details: Initially we were running with 32-bit Tomcat 7.0.23 and saw that our shutdown sequence was not being logged at all when one of our customers shut down his laptop. It looked like the process was just being killed. I found a commons-daemon/procrun bug and corresponding fix that seemed like it should address the issue, namely http://stackoverflow.com/questions/13578196/how-to-gracefully- shutdown -procrun/14150785#14150785 https://issues.apache.org/jira/browse/DAEMON-274 I subsequently upgraded Tomcat to 7.0.36 (32-bit, zip) to get the updated commons-daemon (http://tomcat.apache.org/tomcat-7.0- doc/changelog.html), but to no avail. I thought perhaps the 32-bit Tomcat/64-bit OS might be a disconnect, so I installed the 64-bit version, but got the same result. In short, it looks like we're either doing something wrong with our code, or there's a new wrinkle in the OS-service handshaking, or the bug wasn't fixed correctly...maybe in that order. Details below on how our code manifested the problem as well as other steps to reproduce. Our database shutdown code is located in the destroy() function of a class implementing org.springframework.beans.factory.DisposableBean. I added a Thread.sleep(5 min) call to reproduce it on my machine. As long as I shut down the service through the Services panel on Windows, the shutdown sequence fully executes (and takes 5 min, as expected). But if I just shut down Windows, the sequence is interrupted. 1. From the above I would say that is a Windows feature, that it does not wait for service to shutdown properly. I'd look into Windows support and MSDN, whether it is a configuration issue or something that be workaround by proper coding. I proposed three options to Steve to change the Windows configuration to either allow more time, or to make Tomcat shutdown dependent on the database shutdown, or both. 2. On the Shutdown tab of the procrun service configuration dialog (Tomcat7w.exe) there is Timeout field. I have 0 (sec) there. A good option, but it will not necessarily override the Windows default of 12 seconds to shut down a service. Jeffrey Harris This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments. - Sorry, Jeffrey -- and thanks for pointing out your suggestions again -- I only saw your topmost comment last time around establishing a dependency on HSQLDB. I will check out your other options. Regards, Steve This message is intended only for the named recipient. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action based on the contents of this information is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Procrun and Tomcat service/OS shutdown on Windows
-Original Message- From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] Sent: Friday, March 15, 2013 12:11 AM To: Tomcat Users List Subject: Re: Procrun and Tomcat service/OS shutdown on Windows On Thu, Mar 14, 2013 at 12:00 PM, Thomas, Steve stho...@vocollect.comwrote: Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a service (either via service.bat or the exe installer) on a Windows 7 64-bit OS, we are seeing an issue where the Windows shutdown kills Tomcat before our webapp shutdown sequence has time to execute fully. (Specifically, we just want to make sure our instance of HSQLDB shuts down correctly, otherwise corruption can ensue.) Few months ago, my web app was running on Windows Server 2003 R2, 32-bit Client JVM and Tomcat versions 7.0.34 and 7.0.35. Within the last 3 months, my web app has been running on Windows Server 2008 R2, 64-bit Server JVM, and Tomcat version 7.0.35 and 7.0.37 (since I am running TomEE 1.5.2+). anyway, Windows shutdown and restarted itself because of Windows Updates (automatic updates) and i have experienced at least 1 power outage due to storm(s), and my Apache Derby (embedded) has not corrupted yet, at all. My manager has had our app and HSQLDB running for a while on his laptop and hasn't seen an issue, either. Our customer had several shutdowns where everything was fine (even though the shutdown sequence wasn't even started) and then had a couple where we had gotten so far as to issue the SHUTDOWN command to HSQLDB and then the database came back corrupt on the next startup. Thanks for your input...still reviewing the posts today. Regards, Steve This message is intended only for the named recipient. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action based on the contents of this information is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: configuring tomcat7 with apache 2.2.22
In this scenario, both tomcat and apache are running on the same workstation (doesn't have to be, just give the ip of the tomcat server in the script), and access is to intranet users only. Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com ---Original Message--- From: Jan Vávra va...@602.cz To: Tomcat Users List users@tomcat.apache.org Subject: Re: configuring tomcat7 with apache 2.2.22 Sent: Mar 15 '13 09:32 In this situation are both server exposed - Apache Server and Apache Tomcat. It can work. When you use reverse proxy only the Apache Server is exposed. So configuring a ssl certificate is only done once. On client computer/network there could be allowed only the standard http port 80 and not 8080. Depends on situation ... Jan. Thanks to some advice on this forum, and a lot of independent study and experimentation, I have a php app on apache (localhost:80) pulling in a database driven bar code from a IDAutomation Servlet running on tomcat (localhost:8080). Looks like this - $bcode = $row['Bar Code'] ; $beginurl = img src='http://localhost:8080/examples/servlet/LinearServlet?BARCODE=;; $endurl = BAR_HEIGHT=.5S=UPCA'; echo $beginurl . $bcode . $endurl; Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com ---Original Message--- From: Jan Vávra va...@602.cz To: Tomcat Users List users@tomcat.apache.org Subject: Re: configyuring tomcat7 with apache 2.2.22 Sent: Mar 15 '13 07:43 Hello, I take care about an app that is a combination of Apache Server+php Drupal app and Apache Tomcat jsp app. Apache Server listens on the ports 80/443 and requests are reverse proxied to Apache Tomcat. Let's say that the tomcat app resides on/testca The apache server config will be ProxyRequests Off ProxyPass /testca ajp://127.0.0.1:9081/testca ProxyPassReverse /testca ajp://127.0.0.1:9081/testca Proxy /testca/WEB-INF Order Deny,Allow Deny from All /Proxy Proxy /testca Order Deny,Allow Allow from All /Proxy and check if ajp module is loaded: LoadModule proxy_ajp_module modules/mod_proxy_ajp.so In the Apache Tomcat's server.xml change ajp port to 9081 Connector port=9081 protocol=AJP/1.3 redirectPort=8443 / On WinXP there should be no problem. I personally develop on Win 7, production is Linux. Jan. Although not a newbie to building websites in html and php, and physical computing in C/C++, I'm having a dickens of a time understanding the documentation of Integrating Tomcat 7 with my existing Apache 2.2.22 on WinXP (company supplied development pc, nothing I can do about that). Can I get a bit of handholding please? I'm trying to evaluate a java servlet that requires tomcat. Steve Spence, KK4HFJ http://arduinotronics.blogspot.com http://www.essnmag.com - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
Hey Rainer, attached you can find a Threaddump. Just rename it to .zip. I'm not sure waht all the stuff at the dump means. but I'm sure you know.. :-) thanks Please please before restarting take two thread dumps. On Linux/Unix a kill -QUIT will do that (and write the result to STDOUT, which depending on your setup likely goes to catalina.out). The QUIT signal does *not* terminate the JVM, it just quickly writes out the stacks of all threads. The interruption for the running JVM is minimal, so you can already try how this works before the process gets into the critical state. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
On 15.03.2013 15:44, David Kumar wrote: Hey Rainer, attached you can find a Threaddump. Just rename it to .zip. I'm not sure waht all the stuff at the dump means. but I'm sure you know.. :-) It got stripped by the list. Can you post it somewhere and make the URL available? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Standard or OCSP Native Lib?
On 03/15/2013 02:39 AM, Nick Williams wrote: Can anyone shed some light on when you would pick standard and when you would pick OCSP? I think that's usage is self explanatory. Use OCSP if you need OCSP :) Otherwise it'll just slow you down. Since the current implementation does not have enable/disable configuration the only way was to make it compile time enabled/disabled. In future I see those two will become one version with runtime selection. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mail/Session resources lookup fail
I have a typical mail resource set up but my lookup always returns localhost as the smtp host. My webapp contect.xml looks like this: ?xml version=1.0 encoding=UTF-8? context Resource name=mail/Session auth=Container type=javax.mail.Session mail.smtp.host=smtp.mydomain.com mail.debug=true/Resource /context My webapp web.xml has an entry like this: resource-ref descriptionResource reference to a factory for javax.mail.Session instances that may be used for sending electronic mail messages, preconfigured to connect to the appropriate SMTP server./description res-ref-namemail/Session/res-ref-name res-typejavax.mail.Session/res-type res-authContainer/res-auth /resource-ref My webapp code Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); javax.mail.Session msession = (javax.mail.Session) envCtx.lookup(mail/Session); System.out.println(msession to string is + msession.getProperty(mail.smtp.host)); For some reasons, this work on my Eclipse/Tomcat set up but when I deploy everything to another server, the getProperty always return localhost as the smtp host. I search for all Tomcat log files but could not find anything. Any ideas? Thanks in advance! Alex
Re: Tomcat jdbc pool connection failover
On Wed, Mar 13, 2013 at 12:52 PM, André Warnier a...@ice-sa.com wrote: Rainer Frey wrote: On 12.03.2013, at 17:14, Christopher Schultz ch...@christopherschultz.net wrote: On 3/12/13 7:54 AM, amit shah wrote: I am using Oracle. Oracle JDBC Driver provides the Oracle Universal Connection Pool (UCP) which includes this feature http://docs.oracle.**com/cd/E11882_01/java.112/**e16548/fstconfo.htmhttp://docs.oracle.com/cd/E11882_01/java.112/e16548/fstconfo.htm of connection failover but since we use tomcat jdbc connection pool we cannot use UCP. Why not? Because it would be two-level pooling? Also UCP has lot of synchronized code which leads to blocking threads and less concurrency support. Let me know your suggestions/thoughts. I'm thinking that a low-performance fail-over is preferable to a zero-performance non-fail-over. Well, low overall performance, but possibility of failover in the hopefully rare case, may not be acceptable compared to high(er) overall performance and a search for other ways to perform failover. I am not sure that I totally follow the arguments here, but it seems that there exist - a JDBC pool with good performance, but no fail-over - a JDBC pool with failover, but bad performance Why not move the problem one level higher, and instead of using one tomcat with several pools, use several tomcats each with their own pool ? Several tomcats can be configured as a failover pool of tomcats, no ? I am using the tomcat jdbc pool independently by placing the jars in my web-application. We use glassfish as our application server. So what you suggest is not an option. --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Changing tomcat connection pool size through jmx
It indeed works. Thanks ! On Fri, Mar 8, 2013 at 6:40 PM, Daniel Mikusa dmik...@vmware.com wrote: On Mar 7, 2013, at 10:11 PM, Amit wrote: I tried setting the 'maxActive' attribute by double clicking it and modifying the value but the new value does not get set. What happens? Do you get an error? If so, what does it say? The bug 50864 was suppose to provide the flexibility to update the connection pool properties through JMX and this is what I was looking for. Shouldn't that be the case? Tested with Tomcat 7.0.37 and it works fine for me. Steps used to test: 1.) Configure Global Resource tag using H2 database 2.) Start Tomcat 7.0.37 3.) Connect using jvisualvm 4.) Go to MBeans tab 5.) Browse to tomcat.jdbc - ConnectionPool - pool-name - org.apache.tomcat.jdbc.pool.DataSource. 6.) Double click maxActive, change value, press enter. 7.) Value is saved. Refreshing shows the new value. Dan thanks. On 08-Mar-2013, at 1:40 AM, Daniel Mikusa dmik...@vmware.com wrote: On Mar 7, 2013, at 12:32 PM, amit shah wrote: I was looking at jmx since that would not need application server restart. I didn't understand what you meant by Have you tried looking at / modifying the attributes ? When you look at an Mbean in jconsole or jvisualvm, you'll see a few different tabs but there should be one which lists Attributes (i.e. the values exposed through JMX) and one that lists Operations (i.e. functions exposed through JMX). Attributes list the properties of an mbean and some properties can be changed on the fly by double-clicking them and setting a new value. I believe that's how you would adjust the connection pool properties. Does that work for you? Dan On Thu, Mar 7, 2013 at 9:50 PM, Daniel Mikusa dmik...@vmware.com wrote: On Mar 7, 2013, at 9:59 AM, amit shah wrote: Hello, I use tomcat connection pool in my web application by using two jars - tomcat-jdbc-7.0.34.jar and tomcat-juli-7.0.34.jar. I want to change the connection pool size through jmx but I could not find any defined jmx operation for doing that. Are you strictly looking at JMX operations? Have you tried looking at / modifying the attributes? Dan I noticed that bug 50864https://issues.apache.org/bugzilla/show_bug.cgi?id=50864 specifies that tomcat allows updating the connection pool size through jmx from tomcat 7.0.28 onwards. I use 7.0.34 version for jars. Am I missing something? Thank you - 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 - 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: Standard or OCSP Native Lib?
On Mar 15, 2013, at 10:21 AM, Mladen Turk wrote: Otherwise it'll just slow you down. That's what I was looking for. I didn't see any indication anywhere that OCSP came with a performance hit, so my thought was, why wouldn't you just always use the OCSP version? Thanks for clarifying this. Since the current implementation does not have enable/disable configuration the only way was to make it compile time enabled/disabled. In future I see those two will become one version with runtime selection. That would certainly be an improvement, in my mind. :-) Thanks, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6.0.35 in production maintaince
On Thu, Mar 14, 2013 at 07:13:20AM -0700, fachhoch wrote: every few seconds a new session is begin created from an ipaddress , I have no clue who owns that ipaddress , how can I find more about that ipaddress? 'whois'. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu There's an app for that: your browser pgptV0Om_cGmR.pgp Description: PGP signature
Re: JNDI property roleSearchAsUser not working as expected
Am 14.03.2013 15:54, schrieb Eugène Adell: I still wonder, why you are so reluctant to use a technical user. Especially since you have security concerns about the anonymous user. To find someone's roles, LDAP only requires a bind + a search in groups. It is a simple ldapsearch command for the ones using command lines. But you have to know which user is doing the search, right? Tomcat does not know which user is logging in at start, it will search for the user with one of the methods 'userSearch' or 'userPattern'. The first will have to do a search to find the users dn, the second one could theoretically build the dn and do a bind. But since the 'userPattern' approach can be configured to have more than one dn to look up, it would have to do more than one login try, which could be harmful for the performance, if your directory server gives penalty pauses for wrong credentials. But when connecting through Tomcat we also need extra either one more account or allowing anonymous bind. This is not logical to add extra work to anything which could stay simple. see above. About security, we can ask any user to change its password on a monthly or quarterly basis. The technical account should be under the same security control with expiring passwords and it is not good practice to stop client applications especially when there are many, or in production environment. The anonymous bind is free from such problem, and it's not much worse than a password stored in a config file. I don't think, that it is necessary to use the same security enforcement for technical users as for real users, but every one will have a different opinion on security policies, so yours is as valid as every ones :) On the other hand, given the frequent updates of tomcat itself, you will have to restart your servers in order to stay updated quite often already... Regards Felix De : Felix Schumacher [felix.schumac...@internetallee.de] Envoyé : jeudi 14 mars 2013 15:28 À : Tomcat Users List Objet : RE:RE:JNDI property roleSearchAsUser not working as expected Eugène Adell eugene.ad...@d2-si.eu schrieb: Thanks Felix, I will choose the easy way by allowing the anonymous to bind the directory, against all security logics, and strengthen the ACL to forbid anonymous search. Anyway, the bug 19444 is closed saying the new parameter (introduced in 7.0.9 and corrected in 7.0.30) allows role searching with the authenticating user. That's true, but we still need either the anonymous or a technical user for the startup binding. It's not really compliant to real-life LDAP management. I still wonder, why you are so reluctant to use a technical user. Especially since you have security concerns about the anonymous user. Regards Felix best regards De : Felix Schumacher [felix.schumac...@internetallee.de] Envoyé : jeudi 14 mars 2013 14:22 À : Tomcat Users List Objet : RE:JNDI property roleSearchAsUser not working as expected Am 14.03.2013 13:40, schrieb Eugène Adell: This doc is self-contradictory because it suggests to setup a technical user when we don't want to configure a technical user, and it doesn't give any solution when we are not the admin of the directory. I can't read that out of the docs for roleSearchAsUser as stated on http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm It is just a mechanism to switch from the credentials when searching for roles. That way you can restrict the rights to the anonymous/admin user, so that it doesn't need to be able to lookup groups/roles for a user. Here we learn that Tomcat JNDI Realm only works in Administrator Login Mode with an administrator login/password (in fact the technical user discussed above) : http://tomcat.apache.org/tomcat-7.0-doc/funcspecs/fs-jndi-realm.html I believe the Administrator Login Mode is used for retrieving attributes out of an users object and comparing the values to some given credentials. The User Login Mode is used when a bind is performed to check the credentials. But either way, you will have to setup a technical user, or open the directory server to allow anonymous binds and searches for the user dn's. From this, it seems that roleSearchAsUser is only usefull when the anonymous bind is allowed. It's another contradiction here, because it seems logical to use this parameter especially when anonymous is not allowed. You will not get to the point where the role is being searched, since before that there are two points, where your directory is being accessed. 1. initial test of connection (which you reported in your first mail) 2. look up of the user, which wants to login (and since the username to bind with is not known, it will be hard to guess) So as stated before the easiest thing is to just use a technical user to connect to the directory. Regards Felix
Re: Embedded Tomcat JavaDoc Not Complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 3/13/13 2:19 PM, Nicholas Williams wrote: On Wed, Mar 13, 2013 at 12:10 PM, Christopher Schultz ch...@christopherschultz.net wrote: You mean addWebapp methods? They seem fairly self-explanatory. Yes. I meant addWebapp methods. That was a typo. There are three of them. Only one is documented. Unfortunately, the other two are not self explanatory. I have no idea what the url, path, and name parameters are (although host makes sense). The documentation for the lone method that IS documented only has contextPath and baseDir ... that doesn't line up with the other two methods. Yup, it's ugly. Tomcat.addWebapp(String,String) says that the first argument is the context path. The context path for the ROOT webapp is , not /. I didn't know this. I will change it. By the way, I got this code from the tutorial at https://devcenter.heroku.com/articles/create-a-java-web-application-using-embedded-tomcat. They should probably update their HOWTO: / isn't a valid context path, though it might actually work since // ~= / in the URL world. The second argument is a baseDir which says (via Context.setDocBase) it can be an absolute pathname, a relative pathname (to the cwd I suppose, or maybe relative to the hosts's appbase), or a URL. Well there's part of the problem with the documentation. The documentation for the method says Add a webapp using normal WEB-INF/web.xml if found. and the documentation for the baseDir parameter says nothing. There's no information here that would have led me to look at the Context#setDocBase() method. Nada. I will try out making it a URL. I was reading the code, not the Javadoc: it makes it a lot easier. Since the baseDir gets passed into Context.setDocBase, I read the javadoc for that method to get the real story. You are passing a relative path name which probably won't resolve to a resource inside the JAR file you are using. Try fetching a resource URL for the web/ path from the ClassLoader and pass that instead of just web/. I will give this a try. You didn't say what actually happens: just stated your requirements and showed your code. Does Tomcat fail to start? Does it fail to listen on your port? Does it fail to respond to requests? My bad. I'm always seeing y'all tell people to explain the problem, and here I go not explaining the problem just like all the rest of them. :-P ... When I ran the application using the batch file generated by the mojo plugin, almost everything was good (Tomcat started up, started listening on the right port, found all the classes it was supposed to find, etc.). However, I got a severe error that the web application directory (webAppDirLocation) did not exist and the application could not be deployed. Understandable, since I didn't know what to use for this. The likely problem is that your appBase was just web and Tomcat was trying to load that from the disk (directly) instead of looking inside your JAR file. Using a JAR-URL (which the ClassLoader should give you) should work. The URL should look something like /path/to/your.jar!/web or something like that. tomcat.start(); You should probably call tomcat.init() first, though some of the Tomcat test cases don't do it so you're probably okay. Yea, the tutorial I was using didn't say anything about that. Interesting that init and start are separate. If init was required and start didn't call init I would think that start would throw an IllegalStateException. Since it doesn't, my guess is that calling start is sufficient, though I will certainly add init. I would love to now the semantic difference between init and start. The documentation just says Initialize the server and Start the server. Take a look at the Javadoc for LifecycleListener, one of the interfaces that the Tomcat class implements. The Javadoc for any implemented yet not documented method from that interface gets inherited in the javadoc for the implementation class, but the interface-level documentation is, of course, ignored. Go look at the javadoc for that interface and you'll see some nice ASCII art that describes the full lifecycle. tomcat.getServer().await(); } } I don't think you configured any logging. You might want to set up something to at least dump to the console, and crank-up the log level to DEBUG or something like that. Then you might be able to see what Tomcat is actually doing. It does seem to automatically dump to the console automatically. I got plenty of messages, most of them good (listening on 8973, etc.). I will look into logging more, of course. This was just a first pass at proof-of-concept. Cool. Obviously, you're going to want to log to a log file eventually. If you configure commons-logging at the top-level (that is, your own code), I think everything will flow through that. Since sending this email, I've discovered the Executable WAR [2]
Re: Deadlock when using jetty 8 JDBCSessionManager and Tomcat 7 JDBC Connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Colin, On 3/14/13 3:41 PM, Colin Ingarfield wrote: (Sorry I cannot reply correctly b/c I was on the digest list) The deadlocked threads: Deadlock Detection: Found one Java-level deadlock: = qtp1840392480-3740: waiting to lock Monitor@0x7f4350001fd0 (Object@0x0006c01a0e88, a com/mysql/jdbc/JDBC4Connection), which is held by PoolCleaner[2009981184:1363034108768] PoolCleaner[2009981184:1363034108768]: waiting to lock Monitor@0x7f4350001f28 (Object@0x0006c1ed5738, a com/mysql/jdbc/JDBC4ResultSet), which is held by qtp1840392480-3740 Found a total of 1 deadlock. Here are the stack traces: Thread 12820: (state = BLOCKED) - com.mysql.jdbc.ConnectionImpl.getCharacterSetMetadata() @bci=0, line=2851 (Compiled frame) - com.mysql.jdbc.Field.getStringFromBytes(int, int) @bci=37, line=717 (Compiled frame) - com.mysql.jdbc.Field.getName() @bci=17, line=631 (Interpreted frame) - com.mysql.jdbc.ResultSetImpl.buildIndexMapping() @bci=78, line=752 (Compiled frame) - com.mysql.jdbc.ResultSetImpl.findColumn(java.lang.String) @bci=12, line=1110 (Interpreted frame) - com.mysql.jdbc.ResultSetImpl.getString(java.lang.String) @bci=3, line=5609 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager$1.run() @bci=111, line=844 (Interpreted frame) - org.eclipse.jetty.server.handler.ContextHandler.handle(java.lang.Runnable) @bci=53, line=1119 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager.loadSession(java.lang.String, java.lang.String, java.lang.String) @bci=61, line=884 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager.getSession(java.lang.String) @bci=345, line=518 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager.getSession(java.lang.String) @bci=2, line=69 (Interpreted frame) - org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(java.lang.String) @bci=13, line=272 (Interpreted frame) - org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest) @bci=192, line=277 (Interpreted frame) - org.eclipse.jetty.server.session.SessionHandler.doScope(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=47, line=158 (Interpreted frame) - org.eclipse.jetty.server.handler.ContextHandler.doScope(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=416, line=999 (Interpreted frame) - org.eclipse.jetty.server.handler.ScopedHandler.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=13, line=117 (Interpreted frame) - org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=399, line=250 (Interpreted frame) - org.eclipse.jetty.server.handler.HandlerCollection.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=42, line=149 (Compiled frame) - org.eclipse.jetty.server.handler.HandlerWrapper.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=23, line=111 (Compiled frame) - org.eclipse.jetty.server.Server.handle(org.eclipse.jetty.server.AbstractHttpConnection) @bci=134, line=350 (Compiled frame) - org.eclipse.jetty.server.AbstractHttpConnection.handleRequest() @bci=228, line=454 (Compiled frame) - org.eclipse.jetty.server.AbstractHttpConnection.headerComplete() @bci=448, line=890 (Interpreted frame) - java.util.HashMap.get(java.lang.Object) @bci=74, line=320 (Compiled frame) - org.eclipse.jetty.io.BufferCache.get(org.eclipse.jetty.io.Buffer) @bci=5, line=59 (Compiled frame) - org.eclipse.jetty.http.HttpParser.parseNext() @bci=625, line=371 (Compiled frame) - org.eclipse.jetty.http.HttpParser.parseAvailable() @bci=1, line=230 (Compiled frame) - org.eclipse.jetty.server.AsyncHttpConnection.handle() @bci=80, line=77 (Compiled frame) - org.eclipse.jetty.io.nio.SslConnection.handle() @bci=36, line=191 (Compiled frame) - org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle() @bci=10, line=606 (Compiled frame) - org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run() @bci=4, line=46 (Interpreted frame) - org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(java.lang.Runnable) @bci=1, line=603 (Compiled frame) - org.eclipse.jetty.util.thread.QueuedThreadPool$3.run() @bci=47, line=538 (Compiled frame) - java.lang.Thread.run() @bci=11, line=679
Re: check load
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fachhoch, On 3/14/13 5:30 PM, fachhoch wrote: is there any way I can check load on the server , my loadbabalncer calls a web resource to check if server is able to handle request , if time for repononse exceeds specified linit it launches a new server instance to handle request.Please advice me what is the best way to detect load on a server ? What is your definition of load? Wow... you spin-up a new server instance just to handle a single request? That's certainly going to increase the load somewhere significantly. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDdjUACgkQ9CaO5/Lv0PD6qwCfUf3iTzJqZRTqAE0wxGotaBjL 1wUAnRM/sJEsVX5C60RyshZYxgh0wmXl =harK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Running a binary program from a JSP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tim, On 3/14/13 12:34 AM, Tim Gross wrote: I want to know if it is possible to execute a binary program (written in C) from within a JSP. I would like to do this on the server side, not the browser, in Tomcat6. If it is possible, can somebody provide an example. Sorry if I am using the wrong mailing list. Feel free to redirect me if that is the case. Do yourself a favor and: a) Don't do this b) If you have to do it, do it in a servlet, not a JSP c) Limit the number of concurrent requests that are allowed to execute this child process d) Don't forget to flush/consume all your child-process's streams If you don't do (d), you'll probably bring your server to a halt unless nobody ever triggers this particular feature. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDdr8ACgkQ9CaO5/Lv0PAADQCgmZccumNZBXYGjh9r57knUKfl sFkAoJ1BuHia39evFI50mbP03B0T/YHZ =4/BP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NullPointerException in MapperListener; Tomcat#start() does not create a Container?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 3/14/13 5:25 PM, Konstantin Kolinko wrote: 2013/3/15 Nick Williams nicho...@nicholaswilliams.net: I resolved the NullPointerException by calling tomcat.getService().setContainer(tomcat.getEngine()) between init() and start(). Everything is working fine now, and I can go to http://localhost:8973/MyServlet and it's working great, but I still suspect I'm doing something wrong, since no documentation or tutorials anywhere mention needing to do that and it seems that the container should automatically be set on the service... There are a number of working examples in the testsuite. +1 The Tomcat class is used everywhere in the test suites. They even run properly ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDd0QACgkQ9CaO5/Lv0PAbkgCeMiVWMr2rHTmyKI+kfXQIoUDU SGIAnA4sBwbGoPzdwIQ62oF4XxLSQrs8 =0saJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Procrun and Tomcat service/OS shutdown on Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steve, On 3/14/13 1:21 PM, Thomas, Steve wrote: Thanks, Jeffrey. That may be a possibility for the long-term. --Steve Did you read Jeffrey's entire reply? He started by top-posting, but then wrote some much more informative comments at the end of his post. - -chris -Original Message- From: Harris, Jeffrey E. [mailto:jeffrey.har...@mantech.com] Sent: Thursday, March 14, 2013 12:52 PM To: Tomcat Users List Subject: RE: Procrun and Tomcat service/OS shutdown on Windows Edit the registry so Tomcat depends on the HSQLDB shutdown. This only works if HSQLDB is also started as a service. Jeffrey Harris -Original Message- From: Thomas, Steve [mailto:stho...@vocollect.com] Sent: Thursday, March 14, 2013 12:00 PM To: users@tomcat.apache.org Subject: Procrun and Tomcat service/OS shutdown on Windows Hi - Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a service (either via service.bat or the exe installer) on a Windows 7 64-bit OS, we are seeing an issue where the Windows shutdown kills Tomcat before our webapp shutdown sequence has time to execute fully. (Specifically, we just want to make sure our instance of HSQLDB shuts down correctly, otherwise corruption can ensue.) Details: Initially we were running with 32-bit Tomcat 7.0.23 and saw that our shutdown sequence was not being logged at all when one of our customers shut down his laptop. It looked like the process was just being killed. I found a commons-daemon/procrun bug and corresponding fix that seemed like it should address the issue, namely http://stackoverflow.com/questions/13578196/how-to-gracefully-shutdown - - procrun/14150785#14150785 https://issues.apache.org/jira/browse/DAEMON-274 I subsequently upgraded Tomcat to 7.0.36 (32-bit, zip) to get the updated commons-daemon (http://tomcat.apache.org/tomcat-7.0- doc/changelog.html), but to no avail. I thought perhaps the 32-bit Tomcat/64-bit OS might be a disconnect, so I installed the 64-bit version, but got the same result. In short, it looks like we're either doing something wrong with our code, or there's a new wrinkle in the OS-service handshaking, or the bug wasn't fixed correctly...maybe in that order. Details below on how our code manifested the problem as well as other steps to reproduce. Our database shutdown code is located in the destroy() function of a class implementing org.springframework.beans.factory.DisposableBean. I added a Thread.sleep(5 min) call to reproduce it on my machine. As long as I shut down the service through the Services panel on Windows, the shutdown sequence fully executes (and takes 5 min, as expected). But if I just shut down Windows, the sequence is interrupted. (As an aside, I don't expect the shutdown to take anywhere near that long in practice, but wanted to make sure the problem manifested itself so that I could address the bug. We are seeing this with a decent customer test machine, but I can't reproduce it on my machine w/o changes.) Thinking it might be Spring, I moved the shutdown delay to a ServletContextListener. contextDestroyed() method. Same effect. I moved the delay again, and reproduced the same problem in a standalone servlet that overrides HttpServlet.destroy(). I've posted the code at the link below: http://pastebin.com/yYgrQ2sE This is the output recorded in the stdout log file for an OS shutdown, and then a shutdown of the service by hand. We, of course, favor the second. :-) 2013-03-14 10:05:40 Commons Daemon procrun stdout initialized StatusServlet.init() Entering StatusServlet.destroy() Simulating long shutdown sequence. 2013-03-14 10:12:29 Commons Daemon procrun stdout initialized StatusServlet.init() Entering StatusServlet.destroy() Simulating long shutdown sequence. Simulation complete--sequence finished. Exiting StatusServlet.destroy() Can we guarantee that Windows won't just kill our Tomcat process and potentially corrupt our database? That's the question. I'd be grateful for some help on this. Thanks for your time and attention. Steve T This message is intended only for the named recipient. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action based on the contents of this information is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Edit the service entry in the registry (under HKEY_Local_Machine\system\currentcontrolset\services\Tomcat Service Name) so Tomcat depends on HSQLDB. This only works if HSQLDB is also started as a service. If HSQLDB is started some other way (i.e., by the Tomcat web app), you can try and install it as a service using the srvany utility (or
Re: AW: AW: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 DAvid, On 3/13/13 3:01 PM, David Kumar wrote: Hey, right no we're having our Problem. I tried gc through jconsole -- no changes and still a lot CLOSE_WAIT. So it is not a GC Problem and disablereuse doesn't work either.. Any other ideas? What do you guy think about proxy_ajp instead of jk? What are the advantages of proxy_ajp? mod_proxy_ajp uses the identical protocol to mod_jk: they both use AJP, and the code on the Tomcat side is identical. So, if you think this is a Java problem, switching from mod_jk - mod_proxy_ajp is unlikely to change anything at all. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDemcACgkQ9CaO5/Lv0PAt0ACZAZg5UqqAeyEhpuOcssa02p4d DjYAn0IwtT+RJ6pdw+jMX0cy6A8gDhai =A38V -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 3/14/13 11:02 AM, André Warnier wrote: But this is the request/response connection, so I doubt that there would be a bug there, otherwise we'd have problems reports filling this list every day. Might there be that there is somewhere a discrepancy between the keep-alive settings, between Apache and Tomcat ? I'd take a look at the connection timeout settings between mod_jk and Tomcat: if they are mismatched, you might get some weirdness where connections are going stale on the Apache side and not the Tomcat side (or vice-versa). It's easy to do since one side expresses timeouts in ms and the other side in seconds. :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDfBsACgkQ9CaO5/Lv0PD+ggCguhh5KOW+hoxxhwRFIY0AsH8N /30AoJ2sfyMb+xSqewoI0iOSBJRXq0hg =Up57 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Embedded Tomcat JavaDoc Not Complete
On Mar 15, 2013, at 2:15 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 3/13/13 2:19 PM, Nicholas Williams wrote: On Wed, Mar 13, 2013 at 12:10 PM, Christopher Schultz ch...@christopherschultz.net wrote: You mean addWebapp methods? They seem fairly self-explanatory. Yes. I meant addWebapp methods. That was a typo. There are three of them. Only one is documented. Unfortunately, the other two are not self explanatory. I have no idea what the url, path, and name parameters are (although host makes sense). The documentation for the lone method that IS documented only has contextPath and baseDir ... that doesn't line up with the other two methods. Yup, it's ugly. Tomcat.addWebapp(String,String) says that the first argument is the context path. The context path for the ROOT webapp is , not /. I didn't know this. I will change it. By the way, I got this code from the tutorial at https://devcenter.heroku.com/articles/create-a-java-web-application-using-embedded-tomcat. They should probably update their HOWTO: / isn't a valid context path, though it might actually work since // ~= / in the URL world. Yep. The second argument is a baseDir which says (via Context.setDocBase) it can be an absolute pathname, a relative pathname (to the cwd I suppose, or maybe relative to the hosts's appbase), or a URL. Well there's part of the problem with the documentation. The documentation for the method says Add a webapp using normal WEB-INF/web.xml if found. and the documentation for the baseDir parameter says nothing. There's no information here that would have led me to look at the Context#setDocBase() method. Nada. I will try out making it a URL. I was reading the code, not the Javadoc: it makes it a lot easier. Since the baseDir gets passed into Context.setDocBase, I read the javadoc for that method to get the real story. That's how I ended up getting it running: I starting reading code instead of documentation. You are passing a relative path name which probably won't resolve to a resource inside the JAR file you are using. Try fetching a resource URL for the web/ path from the ClassLoader and pass that instead of just web/. I will give this a try. You didn't say what actually happens: just stated your requirements and showed your code. Does Tomcat fail to start? Does it fail to listen on your port? Does it fail to respond to requests? My bad. I'm always seeing y'all tell people to explain the problem, and here I go not explaining the problem just like all the rest of them. :-P ... When I ran the application using the batch file generated by the mojo plugin, almost everything was good (Tomcat started up, started listening on the right port, found all the classes it was supposed to find, etc.). However, I got a severe error that the web application directory (webAppDirLocation) did not exist and the application could not be deployed. Understandable, since I didn't know what to use for this. The likely problem is that your appBase was just web and Tomcat was trying to load that from the disk (directly) instead of looking inside your JAR file. Using a JAR-URL (which the ClassLoader should give you) should work. The URL should look something like /path/to/your.jar!/web or something like that. I tried using a JAR URL. (If I remember correctly, it ended up looking something like jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war.) I tried it as both a directory and a WAR file. Tomcat did not like it. It said Could not deploy web application to [temporary webapps directory location] or something like that. I ended up, at runtime, extracting the war file from the JAR file to a temporary directory and deploying from there. That worked great, and it's how the Tomcat Maven plugin executable war works, too. tomcat.start(); You should probably call tomcat.init() first, though some of the Tomcat test cases don't do it so you're probably okay. Yea, the tutorial I was using didn't say anything about that. Interesting that init and start are separate. If init was required and start didn't call init I would think that start would throw an IllegalStateException. Since it doesn't, my guess is that calling start is sufficient, though I will certainly add init. I would love to now the semantic difference between init and start. The documentation just says Initialize the server and Start the server. Take a look at the Javadoc for LifecycleListener, one of the interfaces that the Tomcat class implements. The Javadoc for any implemented yet not documented method from that interface gets inherited in the javadoc for the implementation class, but the interface-level documentation is, of course, ignored. Go look at the javadoc for that interface and you'll see some nice ASCII art that describes the full lifecycle. Yep. Found that. Last time I
Re: Embedded Tomcat JavaDoc Not Complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 3/15/13 3:56 PM, Nick Williams wrote: I tried using a JAR URL. (If I remember correctly, it ended up looking something like jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war. That doesn't look right. I tried it as both a directory and a WAR file. Tomcat did not like it. It said Could not deploy web application to [temporary webapps directory location] or something like that. I ended up, at runtime, extracting the war file from the JAR file to a temporary directory and deploying from there. That worked great, and it's how the Tomcat Maven plugin executable war works, too. Don't build your own URL. Instead, do this in your driver that calls Tomcat: String docBase = getClass().getResource(/web); String ROOT = ; tomcat.addWebapp(ROOT, docBase); It's probably worth dumping-out the URL just to see what it looks like. Note that your CLASSPATH can affect what getResource() will return, so make sure you don't have too much classpath pollution. I dunno anything about the Tomcat Maven plugin, but I think that an executable WAR file is exactly what you are trying to build. It is. There are some issues (not bugs) with the Tomcat Maven plugin executable war, the first one being that it's not very easy to customize without using command-line arguments (makes it kind of hard to double-click and run the executable war effectively). Also, while there are snapshots for the Tomcat 8.0 embedded artifacts, there is no Tomcat 8.0 version of the Tomcat Maven plugin yet, so I literally can't use it. I ended up using a few maven modules and the embedded Tomcat artifacts to create my own executable WAR. Working great now. Cool. This may be premature (getting it working is my priority), but I should mention that performance is important to what I'm doing here. I'd like to enable the native code. Some applications and libraries include native DLLs/SOs/JNILIBs in their JAR files, copy them to a temporary directory at runtime and load them from the temporary location (to avoid having to actually install the native libraries in the OS or JVM directory structure). Is there a way to do this with an embedded/executable Tomcat application so that the Tomcat classes can take advantage of the native library? I'm almost sure Java won't load a shared library out of a JAR file, so you'll have to use this same technique: extract some shared libraries out of your JAR file and throw them into java.io.tmpdir/pid/shared/* or whatever and then instruct the JVM to load them from there (or modify the java.library.path system property to point to that and let them load naturally). Yea. I got that working. Embedded the DLLs in the JAR file and then extracted at runtime. Learned a lot about how Tomcat loads the native library and filed and created a patch for improvement request #54700 as a result. That bug report offers a silly suggestion: use a system property to configure where tcnative can be found because setting system properties at startup is inconvenient? I suppose that system property would be writable at runtime and so marginally more useful. What about a setting where the native library wasn't loaded *at all* so an embedded driver can load it however it wants? This is a prototype for now, but if we use it for real we'll probably compile and include statically-linked Linux .so and Mac .jnilib files as well, and let the other platforms just run without APR. This won't work without a whole lot of work like sniffing the architecture at runtime and then extracting only the right libraries (or just giving them all different names). Also, if APR doesn't load for some reason, you'll have to configure your SSL Connectors completely differently (using trustStore instead of SSLCertificateKeyFile, etc.), which could be a real pain. Not using SSL, so not concerned here. As for performance itself, you may not actually need APR: if you need SSL, then APR is probably the way to go. If you don't need SSL, stick to the NIO connector which provides comparable performance (from the testing I've done). I dunno if APR provides a faster PRNG than whatever the JVM provides, but I believe the AprLifecycleListener configures Tomcat to use the OpenSSL PRNG which may have some advantages -- I don't actually know. Interesting. My reading on the Tomcat site seemed to indicate APR was better in ALL cases, not just OpenSSL. I will keep this in mind. Nope: from my testing, NIO was a better bet given the additional setup and configuration required by APR. Plus there's a bit of overhead managing the same resources twice (once on the Java side, once on the native side) when using APR. Also a bug in APR can bring-down the whole JVM instead of maybe just throwing an exception for a single request. Basically, if you aren't using SSL, you can abandon tcnative. - -chris -BEGIN PGP SIGNATURE- Version:
Re: tomcat 6.0.35 in production maintaince
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eugène, On 3/14/13 10:40 AM, Eugène Adell wrote: Sure, you can block any IP by configuring a VALVE in the main config file (server.xml) : http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter This requires a server restart. You can also block at the context level, but this requires a context restart. Or if you are running Linux, you can configure the IPTABLES. This one is more expensive to do. iptables is more expensive? Sorry, no: it is much cheaper in terms of OPs time, CPU time, and (lack of) downtime. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDgn4ACgkQ9CaO5/Lv0PBWNACgnKQg+xdERJ6sAYmo+0McYeww 01AAoMEtyOf4OcmEXrs/M5cmQl8J3vtd =48/M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6.0.35 in production maintaince
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fachhoch, On 3/14/13 8:01 AM, fachhoch wrote: I added all my jsp with %@ page session=false % still session count is increasing , is there any session listner which will debug all session creation ,time ,ipaddress etc and session destroy You can write your own: they are trivial to write if you just want to log what code is creating the session. Capturing information about the request is less easy: you have to write a Filter that wraps the requests and instruments them. That's also fairly easy but does require a certain amount of familiarity with the Servlet API. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDgvoACgkQ9CaO5/Lv0PBf1QCfUBkcFdHEli8Wzfb6MGS1fwn3 tLkAn2xcApmBBmr7wIvoGio6hiqy99ic =MAAO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Best Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 3/15/13 4:02 PM, Jeffrey D. Fisher wrote: I am looking for a published best practice on editing the SERVER.XML configuration file to use SSL/HTTPS. The key are imported into the keystore. Any input is appreciated. What documentation have you read so far? What steps have you taken? What kind of Connector are you using? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDg3kACgkQ9CaO5/Lv0PBxwgCgtvWSU8gJGyvt+3BqADImfLyI DMwAni+NRXYq6F31B7lWFrb4Vbrzv3hc =20Dg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unix domain socket leak using NIO connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lucian, On 3/15/13 4:03 PM, Lucian I wrote: We are seeing a leak of Unix domain sockets in Tomcat 7.0.26 configured to run with Http11NioProtocol connector. This is running in Ubuntu Linux 12.04.1 LTS with OpenJDK 6u24. The leak is about 15 Unix domain sockets per hour (based on our typical request rate), and is reaching the 4096 file limit we configured in 10 days. These Unix domain sockets tied to the Tomcat process can be seen by issuing lsof command (e.g. lsof | grep tomcat7 | grep socket). Can we get a sample of that output? I'm fairly sure that Java does not provide access to UNIX domain sockets, so this would have to be at the JVM implementation layer. Obviously, Tomcat could be mismanaging some resource which ultimately leaks these things at the native level, but it's not like we can grep the Tomcat code for new UNIXDomainSocket or anything like that. The leak is absent when Tomcat runs using the BIO connector, and this would indicate a problem in the NIO connector implementation. I've seen the same situation indicated by someone else in the past, but with no response: http://mail-archives.apache.org/mod_mbox/tomcat-users/201201.mbox/%3CCAJkSUv-DDKTCQ-pD7W=qovmph1dxexovcr+3mcgu05cqpt7...@mail.gmail.com%3E There certainly was a response: http://markmail.org/message/wvurlmltc4mxtrcp If you can provide more information, I'm sure it will help to diagnose any problem. Are you able to upgrade to the current version of Tomcat 7? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDhS8ACgkQ9CaO5/Lv0PAr8gCgvAAXZkMQetf2UpsxlPfei9BC YesAnjeYavpJsW5cN4sOuj/nowE7ODs/ =5nyS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Embedded Tomcat JavaDoc Not Complete
On Mar 15, 2013, at 3:15 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 3/15/13 3:56 PM, Nick Williams wrote: I tried using a JAR URL. (If I remember correctly, it ended up looking something like jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war. That doesn't look right. That's what Class#getResource() returned. I tried it as both a directory and a WAR file. Tomcat did not like it. It said Could not deploy web application to [temporary webapps directory location] or something like that. I ended up, at runtime, extracting the war file from the JAR file to a temporary directory and deploying from there. That worked great, and it's how the Tomcat Maven plugin executable war works, too. Don't build your own URL. Instead, do this in your driver that calls Tomcat: String docBase = getClass().getResource(/web); String ROOT = ; tomcat.addWebapp(ROOT, docBase); I was using Class#getResource() just like this. However, Class#getResource() does not return a String. It returns a java.net.URL. I can't just pass that to addWebapp(), I had to toString() it. Just to be accurate, I ran it again and dumped the URL again (I was doing this before for debugging, but I had removed it). It's jar:file:/C:/Users/Nicholas/Desktop/PeripheralProxy/TomcatRunner/target/Peripher alProxy-1.0.0.SNAPSHOT.jar!/PeripheralProxy.war. So my memory was close, but not exact. It's probably worth dumping-out the URL just to see what it looks like. Note that your CLASSPATH can affect what getResource() will return, so make sure you don't have too much classpath pollution. I dunno anything about the Tomcat Maven plugin, but I think that an executable WAR file is exactly what you are trying to build. It is. There are some issues (not bugs) with the Tomcat Maven plugin executable war, the first one being that it's not very easy to customize without using command-line arguments (makes it kind of hard to double-click and run the executable war effectively). Also, while there are snapshots for the Tomcat 8.0 embedded artifacts, there is no Tomcat 8.0 version of the Tomcat Maven plugin yet, so I literally can't use it. I ended up using a few maven modules and the embedded Tomcat artifacts to create my own executable WAR. Working great now. Cool. This may be premature (getting it working is my priority), but I should mention that performance is important to what I'm doing here. I'd like to enable the native code. Some applications and libraries include native DLLs/SOs/JNILIBs in their JAR files, copy them to a temporary directory at runtime and load them from the temporary location (to avoid having to actually install the native libraries in the OS or JVM directory structure). Is there a way to do this with an embedded/executable Tomcat application so that the Tomcat classes can take advantage of the native library? I'm almost sure Java won't load a shared library out of a JAR file, so you'll have to use this same technique: extract some shared libraries out of your JAR file and throw them into java.io.tmpdir/pid/shared/* or whatever and then instruct the JVM to load them from there (or modify the java.library.path system property to point to that and let them load naturally). Yea. I got that working. Embedded the DLLs in the JAR file and then extracted at runtime. Learned a lot about how Tomcat loads the native library and filed and created a patch for improvement request #54700 as a result. That bug report offers a silly suggestion: use a system property to configure where tcnative can be found because setting system properties at startup is inconvenient? I suppose that system property would be writable at runtime and so marginally more useful. That was exactly the point. For my purposes, I have to sniff out the architecture at runtime (really not as hard as you suggest below, only took me about 10 minutes to write) and THEN determine which library to use. System#setProperty() makes it easy to then tell Tomcat where the library is. But you can't change the java.library.path at runtime with setProperty() (you can, it has just already been cached, so you have to use reflection on a JVM class to clear the cache, which isn't pretty). Even specifying this property on the command line at JVM startup is STILL easier than changing the java.library.path property at startup, because java.library.path isn't always constructed the same way across platforms, and changing it has some inherent risk. What about a setting where the native library wasn't loaded *at all* so an embedded driver can load it however it wants? I'm not sure what you're suggesting here. This is a prototype for now, but if we use it for real we'll probably compile and include statically-linked Linux .so and Mac .jnilib files as well, and let the other platforms just run without APR. This won't work without a
ThreadLocal variables and BIO/NIO/APR
I know, I know. Don't use ThreadLocals. I've seen it on this list at least 100 times. But avoiding ThreadLocal variables can be hard: 1) Spring Framework uses ThreadLocals for things like the RequestContext. You can't just turn that off. 2) Spring Security uses ThreadLocals for things like the security context. Can't turn that off, either. 3) Using ServletRequest#setAttribute()/getAttribute() or HttpSessions aren't always useable replacements for ThreadLocal variables. Doing this couples all aspects of your application to ServletRequests and/or HttpSessions. For example, in a multi-tenant environment, you need to establish some context that identifies which persistence location to use for obtaining and persisting data. Having to pass a request or session from servlet to service to repository is not ideal. Neither, for that matter, is having to have a tenant parameter (or any other type of identifying parameter) added to every single method in the entire application. And, when you're dealing with existing interfaces (Spring, Hibernate) that you have to implement, this isn't even an option sometimes. So, with that in mind, the logical question is, how does one use ThreadLocals safely and reliably? The obvious first step is, don't let them leak. That's easily solved. We have a filter that performs the setting of all of our ThreadLocals on the way in, and it also clears them on the way back out. The ThreadLocalLeakPreventionListener helped us identify 1 or 2 situations where they were still leaking, and we fixed those, too. But, reading about the differences between BIO/NIO/APR, I'm concerned that may not be enough. If I understand this correctly (which I may not), BIO dedicates a thread to a request from beginning to end and then recycles that thread only when the request has completed (which is perfect), but NIO and APR do not do that. More than one request may use a given thread at (kind of) the same time. So my concern is that ThreadLocals from one request could pollute ThreadLocals in another request. Is this a concern, or are there reasons that won't happen? I don't really understand how any of this works, so some advice is greatly appreciated. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ThreadLocal variables and BIO/NIO/APR
2013/3/16 Nick Williams nicho...@nicholaswilliams.net: I know, I know. Don't use ThreadLocals. I've seen it on this list at least 100 times. But avoiding ThreadLocal variables can be hard: 1) Spring Framework uses ThreadLocals for things like the RequestContext. You can't just turn that off. 2) Spring Security uses ThreadLocals for things like the security context. Can't turn that off, either. 3) Using ServletRequest#setAttribute()/getAttribute() or HttpSessions aren't always useable replacements for ThreadLocal variables. Doing this couples all aspects of your application to ServletRequests and/or HttpSessions. For example, in a multi-tenant environment, you need to establish some context that identifies which persistence location to use for obtaining and persisting data. Having to pass a request or session from servlet to service to repository is not ideal. Neither, for that matter, is having to have a tenant parameter (or any other type of identifying parameter) added to every single method in the entire application. And, when you're dealing with existing interfaces (Spring, Hibernate) that you have to implement, this isn't even an option sometimes. So, with that in mind, the logical question is, how does one use ThreadLocals safely and reliably? The obvious first step is, don't let them leak. That's easily solved. We have a filter that performs the setting of all of our ThreadLocals on the way in, and it also clears them on the way back out. The ThreadLocalLeakPreventionListener helped us identify 1 or 2 situations where they were still leaking, and we fixed those, too. But, reading about the differences between BIO/NIO/APR, I'm concerned that may not be enough. If I understand this correctly (which I may not), BIO dedicates a thread to a request from beginning to end and then recycles that thread only when the request has completed (which is perfect), but NIO and APR do not do that. More than one request may use a given thread at (kind of) the same time. So my concern is that ThreadLocals from one request could pollute ThreadLocals in another request. Is this a concern, or are there reasons that won't happen? I don't really understand how any of this works, so some advice is greatly appreciated. Java call chain belongs to a single thread. That is how the language works, regardless of connectors. As long as you clear it in the same place where you set it (a-la try/finally) you should not worry. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ThreadLocal variables and BIO/NIO/APR
On 15/03/2013 20:53, Nick Williams wrote: If I understand this correctly (which I may not), BIO dedicates a thread to a request from beginning to end and then recycles that thread only when the request has completed (which is perfect), but NIO and APR do not do that. More than one request may use a given thread at (kind of) the same time. So my concern is that ThreadLocals from one request could pollute ThreadLocals in another request. Is this a concern, or are there reasons that won't happen? Normally, all three connectors dedicate a thread to the processing of a request from beginning to end. You can safely use ThreadLocals in the manner you describe with any connector. However, if you start to use Servlet 3.0 Async then you need to be a little more careful. Once you enter async mode ThreadLocals are almost certainly going to start causing problems. The same goes for Servlet 3.1 non-blocking IO. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unix domain socket leak using NIO connector
Hi Christopher, My bad for not seeing the response to the similar question posted last year. Using lsof: $ lsof | grep tomcat7 | grep socket | head -2 java 1341 tomcat7 74u unix 0x88007a26a3c0 0t0 16985 socket java 1341 tomcat7 98u unix 0x88007a26a3c0 0t0 16985 socket .. The count of these unix domain sockets keeps increasing and they belong to the same Tomcat process with PID 1341. I've talked to someone that is able to run a load test again and he's going to use Tomcat 7.0.37 now and see if it makes a difference. I'll know that next Tuesday and let you know. I know there is no JDK API to create a Unix domain socket, but, apparently, the JVM may create them when the application is using NIO API, and that was a surprise for me as well. Something that caught my eye was posted here: http://stackoverflow.com/questions/7038688/java-nio-causes-file-descriptor-leak That guy implemented his own server using Java NIO and ran into the same leak by cancelling the selection key in one thread and closing the socket channel in another thread. I don't know whether this is the case in Tomcat, but it's something to consider if someone familiar with the implementation is willing to do a bit of code inspection. Thanks for looking at it, Lucian On Fri, Mar 15, 2013 at 4:31 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lucian, On 3/15/13 4:03 PM, Lucian I wrote: We are seeing a leak of Unix domain sockets in Tomcat 7.0.26 configured to run with Http11NioProtocol connector. This is running in Ubuntu Linux 12.04.1 LTS with OpenJDK 6u24. The leak is about 15 Unix domain sockets per hour (based on our typical request rate), and is reaching the 4096 file limit we configured in 10 days. These Unix domain sockets tied to the Tomcat process can be seen by issuing lsof command (e.g. lsof | grep tomcat7 | grep socket). Can we get a sample of that output? I'm fairly sure that Java does not provide access to UNIX domain sockets, so this would have to be at the JVM implementation layer. Obviously, Tomcat could be mismanaging some resource which ultimately leaks these things at the native level, but it's not like we can grep the Tomcat code for new UNIXDomainSocket or anything like that. The leak is absent when Tomcat runs using the BIO connector, and this would indicate a problem in the NIO connector implementation. I've seen the same situation indicated by someone else in the past, but with no response: http://mail-archives.apache.org/mod_mbox/tomcat-users/201201.mbox/%3CCAJkSUv-DDKTCQ-pD7W=qovmph1dxexovcr+3mcgu05cqpt7...@mail.gmail.com%3E There certainly was a response: http://markmail.org/message/wvurlmltc4mxtrcp If you can provide more information, I'm sure it will help to diagnose any problem. Are you able to upgrade to the current version of Tomcat 7? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFDhS8ACgkQ9CaO5/Lv0PAr8gCgvAAXZkMQetf2UpsxlPfei9BC YesAnjeYavpJsW5cN4sOuj/nowE7ODs/ =5nyS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ThreadLocal variables and BIO/NIO/APR
On Mar 15, 2013, at 4:05 PM, Mark Thomas wrote: On 15/03/2013 20:53, Nick Williams wrote: If I understand this correctly (which I may not), BIO dedicates a thread to a request from beginning to end and then recycles that thread only when the request has completed (which is perfect), but NIO and APR do not do that. More than one request may use a given thread at (kind of) the same time. So my concern is that ThreadLocals from one request could pollute ThreadLocals in another request. Is this a concern, or are there reasons that won't happen? Normally, all three connectors dedicate a thread to the processing of a request from beginning to end. You can safely use ThreadLocals in the manner you describe with any connector. However, if you start to use Servlet 3.0 Async then you need to be a little more careful. Once you enter async mode ThreadLocals are almost certainly going to start causing problems. The same goes for Servlet 3.1 non-blocking IO. Ahh. That makes sense. We are not currently using Async or non-blocking IO. We may at some point in the future. We will be sure to be careful with how we handle ThreadLocals at that point. Thanks! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deadlock when using jetty 8 JDBCSessionManager and Tomcat 7 JDBC Connector
On Fri, Mar 15, 2013 at 2:21 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Colin, On 3/14/13 3:41 PM, Colin Ingarfield wrote: (Sorry I cannot reply correctly b/c I was on the digest list) The deadlocked threads: Deadlock Detection: Found one Java-level deadlock: = qtp1840392480-3740: waiting to lock Monitor@0x7f4350001fd0 (Object@0x0006c01a0e88, a com/mysql/jdbc/JDBC4Connection), which is held by PoolCleaner[2009981184:1363034108768] PoolCleaner[2009981184:1363034108768]: waiting to lock Monitor@0x7f4350001f28 (Object@0x0006c1ed5738, a com/mysql/jdbc/JDBC4ResultSet), which is held by qtp1840392480-3740 Found a total of 1 deadlock. Here are the stack traces: Thread 12820: (state = BLOCKED) - com.mysql.jdbc.ConnectionImpl.getCharacterSetMetadata() @bci=0, line=2851 (Compiled frame) - com.mysql.jdbc.Field.getStringFromBytes(int, int) @bci=37, line=717 (Compiled frame) - com.mysql.jdbc.Field.getName() @bci=17, line=631 (Interpreted frame) - com.mysql.jdbc.ResultSetImpl.buildIndexMapping() @bci=78, line=752 (Compiled frame) - com.mysql.jdbc.ResultSetImpl.findColumn(java.lang.String) @bci=12, line=1110 (Interpreted frame) - com.mysql.jdbc.ResultSetImpl.getString(java.lang.String) @bci=3, line=5609 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager$1.run() @bci=111, line=844 (Interpreted frame) - org.eclipse.jetty.server.handler.ContextHandler.handle(java.lang.Runnable) @bci=53, line=1119 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager.loadSession(java.lang.String, java.lang.String, java.lang.String) @bci=61, line=884 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager.getSession(java.lang.String) @bci=345, line=518 (Interpreted frame) - org.eclipse.jetty.server.session.JDBCSessionManager.getSession(java.lang.String) @bci=2, line=69 (Interpreted frame) - org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(java.lang.String) @bci=13, line=272 (Interpreted frame) - org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest) @bci=192, line=277 (Interpreted frame) - org.eclipse.jetty.server.session.SessionHandler.doScope(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=47, line=158 (Interpreted frame) - org.eclipse.jetty.server.handler.ContextHandler.doScope(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=416, line=999 (Interpreted frame) - org.eclipse.jetty.server.handler.ScopedHandler.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=13, line=117 (Interpreted frame) - org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=399, line=250 (Interpreted frame) - org.eclipse.jetty.server.handler.HandlerCollection.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=42, line=149 (Compiled frame) - org.eclipse.jetty.server.handler.HandlerWrapper.handle(java.lang.String, org.eclipse.jetty.server.Request, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=23, line=111 (Compiled frame) - org.eclipse.jetty.server.Server.handle(org.eclipse.jetty.server.AbstractHttpConnection) @bci=134, line=350 (Compiled frame) - org.eclipse.jetty.server.AbstractHttpConnection.handleRequest() @bci=228, line=454 (Compiled frame) - org.eclipse.jetty.server.AbstractHttpConnection.headerComplete() @bci=448, line=890 (Interpreted frame) - java.util.HashMap.get(java.lang.Object) @bci=74, line=320 (Compiled frame) - org.eclipse.jetty.io.BufferCache.get(org.eclipse.jetty.io.Buffer) @bci=5, line=59 (Compiled frame) - org.eclipse.jetty.http.HttpParser.parseNext() @bci=625, line=371 (Compiled frame) - org.eclipse.jetty.http.HttpParser.parseAvailable() @bci=1, line=230 (Compiled frame) - org.eclipse.jetty.server.AsyncHttpConnection.handle() @bci=80, line=77 (Compiled frame) - org.eclipse.jetty.io.nio.SslConnection.handle() @bci=36, line=191 (Compiled frame) - org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle() @bci=10, line=606 (Compiled frame) - org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run() @bci=4, line=46 (Interpreted frame) - org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(java.lang.Runnable) @bci=1, line=603 (Compiled frame) - org.eclipse.jetty.util.thread.QueuedThreadPool$3.run() @bci=47,
