Re: Connection.close() has already been called during login
On 23/01/2012 03:49, removeps-c...@yahoo.com wrote: > Am running Tomcat 7 and see this in the logs: > > SEVERE: Exception performing authentication > com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: > Connection.close() has already been called. Invalid operation in this state. > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) > at com.mysql.jdbc.Util.getInstance(Util.java:381) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) > at com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018) > at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512) > at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579) > at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408) > at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355) > at pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71) The above line is key. You are not using Tomcat's JDBCRealm. > at > org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) > at > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > > > could the reason be ROOT/META-INF/context.xml which says > > > > driverName="pacific.driver.PacificMysqlDriver" > connectionName="auth" connectionPassword="..." > connectionURL="pacific@jdbc:mysql://localhost:3306" > userTable="user" userNameCol="username" userCredCol="password" > userRoleTable="user_role" roleNameCol="rolename" > digest="SHA1"/> > > That is, should I be using a datasource realm instead? Yes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.35-SocketException: Too many open files issue with
Sorry to possibly state the obvious, but are there perhaps files that are not being closed? This can often happen if code goes into a "catch", and a file is not closed. Best to have a "finally" block which checks if a file is open, and closes it. Robert Purvis -Original Message- From: gnath [mailto:gautam_exquis...@yahoo.com] Sent: 22 January 2012 08:01 To: users@tomcat.apache.org Subject: Tomcat 6.0.35-SocketException: Too many open files issue with Hello, We have been seeing "SocketException: Too many open files" in production environment(Linux OS running Tomcat 6.0.35 with sun's JDK 1.6.30) every day and requires a restart of Tomcat. When this happened for the first time, we searched online and found people suggesting to increase the file descriptors size and we increased to 4096. But still the problem persists. We have the Orion App Server also running on the same machine but usually during the day when we check the open file descriptor by command: ls -l /proc/PID/fd, its always less than 1000 combined for both Orion and Tomcat. Here is the exception we see pouring in the logs once it starts: This requires us to kill java process and restart tomcat. Our Tomcat configuration maxThreadCount is 500 with minSpareThreads=50 in server.xml SEVERE: Socket accept failed java.net.SocketException: Too many open files at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) at java.net.ServerSocket.implAccept(ServerSocket.java:462) at java.net.ServerSocket.accept(ServerSocket.java:430) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:352) at java.lang.Thread.run(Thread.java:662) ulimit -a gives for the user where Tomcat is running. open files (-n) 4096 Please let me know what could be the issue here and how can i resolve this 'Too many open files' issue. Thanks -G This message may contain confidential information. If you are not the intended recipient please inform the sender that you have received the message in error before deleting it. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Thank you for your co-operation. NHSmail is the secure email and directory service available for all NHS staff in England and Scotland NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients NHSmail provides an email address for your career in the NHS and can be accessed anywhere For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: New development, Re: More, Re: Problem bringing up SSL with a CA certificate
James, On 19.1.2012 18:05, James Lampert wrote: You must find keystore with earlier generated key pair (the one you also used to generate CSR for CA), and import all three certificates into that keystore. At this point, I still don't have the keystore used to generate the CSR, but I *do* now have the CSR itself. Does that help? No, it doesn't. Assuming you are NOT using APR connector, the whole procedure goes like this: 1. Generate key pair (public and private key) using keytool -genkeypair. Both keys are kept in the keystore. 2. Export public key into CSR, and send it to the CA. 3. Receive signed public key (certificate) from CA, along with any other necessary certificates forming keychain. 4. Import all received certificates to the keystore you used in step 1. If you lost your keystore, that means that you lost private key. You need to start from the beginning. Generate new keypair, and send it to your CA. Before that, check the revocation procedure with your CA. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cannot rid of expired Certificate ...
-Original Message- From: Brooke Hedrick [mailto:brooke.t.hedr...@gmail.com] Sent: 20 January 2012 12:50 To: Tomcat Users List Subject: RE: Cannot rid of expired Certificate ... On Jan 20, 2012 6:47 AM, "Brooke Hedrick" wrote: > > H > > On Jan 20, 2012 4:23 AM, "Andrew Erskine" wrote: > > > > Top post ? > > > > Win2003svr > > > > Yes correct store .. the only one I've been using .. did try and > > clear the cache on firefox will try ie > > > > Thanks. > > -Original Message- > > From: Pid [mailto:p...@pidster.com] > > Sent: 20 January 2012 09:51 > > To: Tomcat Users List > > Subject: Re: Cannot rid of expired Certificate ... > > > > On 20/01/2012 02:28, Brooke Hedrick wrote: > > > Are you sure you updated the correct keystore? Which o/s are you running? > > > > (Please don't top post.) > > > > It's worth noting that some browsers appear to cache certs and sometimes changes are not immediately apparent. > > > > > > p > > > > > On Jan 19, 2012 2:54 PM, "Darryl Lewis" wrote: > > > > > >> Did you restart tomcat? > > >> > > >> On 20/01/12 5:00 AM, "Andrew Erskine" wrote: > > >> > > >>> I have a self certificate that expired today. > > >>> > > >>> > > >>> > > >>> I removed the certificate from the keystore which the server.xml > > >>> is pointin= g at and generated a new one with the same alias and > > >>> I can see that cert in= the keystore. > > >>> > > >>> > > >>> > > >>> I've been through all my certificate locations on firefox and > > >>> removed any i= nstance > > >>> > > >>> > > >>> > > >>> On restarting tomcat and starting a new browser the website is > > >>> still saying= I have an expired certificate - so where is this > > >>> being picked up > > >> >from ? an= d is there a step I'm missing ? > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Thanks. > > >>> > > >> > > >> > > >> - > > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > >> > > >> > > > > > > > > > -- > > > > [key:62590808] > > > > > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > Where is your keystore located? When running on with Tomcat poviding > the cert, as I recall, there were 2 options of keystore placement. If you are using APR you can specify the location. If not, it assumes it has to look under your 'profile' home. So, c:/documents ands settings/... or c:/users/... Are you using APR? Another question... To rule out the browser, have you tried using openssl to retrieve tthe certificate? The only placement of my keystore is .. keystoreFile="/custom/keystore/cacerts" keystorePass="changeit"> and that is where I have deleted the entry for my server and re-created a new one. Not sure what APR is ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot rid of expired Certificate ...
Andrew Erskine wrote: ... Not sure what APR is ? To save someone else the time : See : http://apr.apache.org/ In essence, "APR" is a software library which contains a number of TCP-socket-related functions which /can/ be used by software applications (such as Apache httpd and Tomcat), as a replacement for similar platform-specific functions, to provide more uniformity. In the case of Tomcat : by default, Tomcat, for its Connectors, uses the network-related functions provided by the Java JVM (e.g., to open a listening socket for a Connector). However, if Tomcat detects the availability of the APR library when it starts, it will switch to using this library instead. The APR implementation is supposed to be more efficient and faster. The importance of this, in the current context, is that there is a difference regarding SSL (HTTPS) : the standard JVM functions use the Java JVM's implementation of SSL, while APR functions use the OpenSSL library. This matters because the relevant Connector attributes are different in each case (and also probably where the software looks for "things" like keystore etc..). You can see if on your system Tomcat has found (and is using) the APR library or not, by examining the Tomcat logfiles : at startup, Tomcat will print a warning if it did not find APR. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cannot rid of expired Certificate ...
-Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 23 January 2012 10:46 To: Tomcat Users List Subject: Re: Cannot rid of expired Certificate ... Andrew Erskine wrote: ... > > Not sure what APR is ? > To save someone else the time : See : http://apr.apache.org/ In essence, "APR" is a software library which contains a number of TCP-socket-related functions which /can/ be used by software applications (such as Apache httpd and Tomcat), as a replacement for similar platform-specific functions, to provide more uniformity. In the case of Tomcat : by default, Tomcat, for its Connectors, uses the network-related functions provided by the Java JVM (e.g., to open a listening socket for a Connector). However, if Tomcat detects the availability of the APR library when it starts, it will switch to using this library instead. The APR implementation is supposed to be more efficient and faster. The importance of this, in the current context, is that there is a difference regarding SSL (HTTPS) : the standard JVM functions use the Java JVM's implementation of SSL, while APR functions use the OpenSSL library. This matters because the relevant Connector attributes are different in each case (and also probably where the software looks for "things" like keystore etc..). You can see if on your system Tomcat has found (and is using) the APR library or not, by examining the Tomcat logfiles : at startup, Tomcat will print a warning if it did not find APR. So I've deleted my certificate again and created a new certificate .. D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 4 entries root, Oct 21, 2011, trustedCertEntry, Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 spectrum-92, Jan 19, 2012, PrivateKeyEntry, Certificate fingerprint (MD5): DF:BA:0D:35:8D:45:E0:79:62:6B:C7:ED:D6:B7:86:8E tomcatss1, Oct 21, 2011, PrivateKeyEntry, Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB D:\win32app\Spectrum\Java\jre\bin>keytool -delete -keystore d:\win32app\Spectrum\custom\keystore\cacerts -alias spectrum-92 Enter keystore password: D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries root, Oct 21, 2011, trustedCertEntry, Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 tomcatss1, Oct 21, 2011, PrivateKeyEntry, Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore keytool error: java.lang.Exception: Keystore file exists, but is empty: d:\win32app\Spectrum\custom\keystore D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: What is your first and last name? [Unknown]: spectrum-92 What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=spectrum-92, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct? [no]: yes Enter key password for (RETURN if same as keystore password): D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 4 entries root, Oct 21, 2011, trustedCertEntry, Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 spectrum-92, Jan 23, 2012, PrivateKeyEntry, Certificate fingerprint (MD5): 8F:26:60:6B:9E:01:64:5E:CB:73:8A:BC:4E:3E:AF:AB tomcatss1, Oct 21, 2011, PrivateKeyEntry, Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB D:\win32app\Spectrum\Java\jre\bin> Heres my server.xml .. Reboot tomcat (stdout.log) Jan 23, 2012 10:58:37 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - (INFO) - Initializing Coyote HTTP/1.1 on http-80 Jan 23, 2012 10:58:39 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - (INFO) - Initializing Coyote HTTP/1.1 on http-443 Jan 23, 2012 10:58:39 AM (m
Re: Cannot rid of expired Certificate ...
Andrew Erskine wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 23 January 2012 10:46 To: Tomcat Users List Subject: Re: Cannot rid of expired Certificate ... Andrew Erskine wrote: ... Not sure what APR is ? To save someone else the time : See : http://apr.apache.org/ In essence, "APR" is a software library which contains a number of TCP-socket-related functions which /can/ be used by software applications (such as Apache httpd and Tomcat), as a replacement for similar platform-specific functions, to provide more uniformity. In the case of Tomcat : by default, Tomcat, for its Connectors, uses the network-related functions provided by the Java JVM (e.g., to open a listening socket for a Connector). However, if Tomcat detects the availability of the APR library when it starts, it will switch to using this library instead. The APR implementation is supposed to be more efficient and faster. The importance of this, in the current context, is that there is a difference regarding SSL (HTTPS) : the standard JVM functions use the Java JVM's implementation of SSL, while APR functions use the OpenSSL library. This matters because the relevant Connector attributes are different in each case (and also probably where the software looks for "things" like keystore etc..). You can see if on your system Tomcat has found (and is using) the APR library or not, by examining the Tomcat logfiles : at startup, Tomcat will print a warning if it did not find APR. So I've deleted my certificate again and created a new certificate .. D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 4 entries root, Oct 21, 2011, trustedCertEntry, Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 spectrum-92, Jan 19, 2012, PrivateKeyEntry, Certificate fingerprint (MD5): DF:BA:0D:35:8D:45:E0:79:62:6B:C7:ED:D6:B7:86:8E tomcatss1, Oct 21, 2011, PrivateKeyEntry, Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB D:\win32app\Spectrum\Java\jre\bin>keytool -delete -keystore d:\win32app\Spectrum\custom\keystore\cacerts -alias spectrum-92 Enter keystore password: D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries root, Oct 21, 2011, trustedCertEntry, Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 tomcatss1, Oct 21, 2011, PrivateKeyEntry, Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore keytool error: java.lang.Exception: Keystore file exists, but is empty: d:\win32app\Spectrum\custom\keystore D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 -keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: What is your first and last name? [Unknown]: spectrum-92 What is the name of your organizational unit? [Unknown]: What is the name of your organization? [Unknown]: What is the name of your City or Locality? [Unknown]: What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: Is CN=spectrum-92, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct? [no]: yes Enter key password for (RETURN if same as keystore password): D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore d:\win32app\Spectrum\custom\keystore\cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 4 entries root, Oct 21, 2011, trustedCertEntry, Certificate fingerprint (MD5): BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, Certificate fingerprint (MD5): 3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 spectrum-92, Jan 23, 2012, PrivateKeyEntry, Certificate fingerprint (MD5): 8F:26:60:6B:9E:01:64:5E:CB:73:8A:BC:4E:3E:AF:AB tomcatss1, Oct 21, 2011, PrivateKeyEntry, Certificate fingerprint (MD5): DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB D:\win32app\Spectrum\Java\jre\bin> Heres my server.xml .. Reboot tomcat (stdout.log) Jan 23, 2012 10:58:37 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - (INFO) - Initializing Coyote HTTP/1.1 on http-80 Jan 23, 2012 10:58:39 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) - (INFO) - Initializing Coyote HTTP/1.1 on http-443 Jan 23
Re: Tomcat 6.0.35-SocketException: Too many open files issue with
Hello Robert, We are talking about an app which has been grown since years and now migrated to Tomcat. Most of the main code is migrated to use spring jdbc and spring 3.0 mvc. Would you recommend some way that i can spot the issue from inspecting the open file descriptors once the server hangs/crashes so that i can check the code to see what you are saying? Please do let me know. All, please help if you can give me any hints from the information i provided down below. Thanks -G From: Purvis Robert (NHS CONNECTING FOR HEALTH) To: Tomcat Users List ; gnath Sent: Monday, January 23, 2012 1:32 AM Subject: RE: Tomcat 6.0.35-SocketException: Too many open files issue with Sorry to possibly state the obvious, but are there perhaps files that are not being closed? This can often happen if code goes into a "catch", and a file is not closed. Best to have a "finally" block which checks if a file is open, and closes it. Robert Purvis -Original Message- From: gnath [mailto:gautam_exquis...@yahoo.com] Sent: 22 January 2012 08:01 To: users@tomcat.apache.org Subject: Tomcat 6.0.35-SocketException: Too many open files issue with Hello, We have been seeing "SocketException: Too many open files" in production environment(Linux OS running Tomcat 6.0.35 with sun's JDK 1.6.30) every day and requires a restart of Tomcat. When this happened for the first time, we searched online and found people suggesting to increase the file descriptors size and we increased to 4096. But still the problem persists. We have the Orion App Server also running on the same machine but usually during the day when we check the open file descriptor by command: ls -l /proc/PID/fd, its always less than 1000 combined for both Orion and Tomcat. Here is the exception we see pouring in the logs once it starts: This requires us to kill java process and restart tomcat. Our Tomcat configuration maxThreadCount is 500 with minSpareThreads=50 in server.xml SEVERE: Socket accept failed java.net.SocketException: Too many open files at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) at java.net.ServerSocket.implAccept(ServerSocket.java:462) at java.net.ServerSocket.accept(ServerSocket.java:430) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:352) at java.lang.Thread.run(Thread.java:662) ulimit -a gives for the user where Tomcat is running. open files (-n) 4096 Please let me know what could be the issue here and how can i resolve this 'Too many open files' issue. Thanks -G This message may contain confidential information. If you are not the intended recipient please inform the sender that you have received the message in error before deleting it. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Thank you for your co-operation. NHSmail is the secure email and directory service available for all NHS staff in England and Scotland NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients NHSmail provides an email address for your career in the NHS and can be accessed anywhere For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail
Tomcat 6.0.35 -crossing maxThreads configured count
Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). We have two connectors (http and ssl) It has been giving some problems like 'too many open files' or just hangs once in a while which requires a restart to get back to normal. Recently i happened to check our access logs when the server hung and stopped responding. We were printing the thread number in the logs and i have seen the number going upto 770 (though the max is configured at 500). I was under impression that the threads will be shared among the connectors and max it can go to 500. Could you please explain why im seeing very high number than configured? Is that maxThreads value per connector? Thanks -G
Re: Tomcat 6.0.35-SocketException: Too many open files issue with
On Mon, 2012-01-23 at 05:33 -0800, gnath wrote: > Hello Robert, > > > We are talking about an app which has been grown since years and now migrated > to Tomcat. Most of the main code is migrated to use spring jdbc and spring > 3.0 mvc. > Would you recommend some way that i can spot the issue from inspecting the > open file descriptors once the server hangs/crashes so that i can check the > code to see what you are saying? Please do let me know. Try running FindBugs on your code. In most cases, it will detect when you do not correctly close a file. Dan > > > All, please help if you can give me any hints from the information i provided > down below. > > > Thanks > -G > > > > > From: Purvis Robert (NHS CONNECTING FOR HEALTH) > To: Tomcat Users List ; gnath > > Sent: Monday, January 23, 2012 1:32 AM > Subject: RE: Tomcat 6.0.35-SocketException: Too many open files issue with > > Sorry to possibly state the obvious, but are there perhaps files that are not > being closed? > > This can often happen if code goes into a "catch", and a file is not closed. > Best to have a "finally" block which checks if a file is open, and closes it. > > > Robert Purvis > > -Original Message- > From: gnath [mailto:gautam_exquis...@yahoo.com] > Sent: 22 January 2012 08:01 > To: users@tomcat.apache.org > Subject: Tomcat 6.0.35-SocketException: Too many open files issue with > > Hello, > > We have been seeing "SocketException: Too many open files" in production > environment(Linux OS running Tomcat 6.0.35 with sun's JDK 1.6.30) every day > and requires a restart of Tomcat. When this happened for the first time, we > searched online and found people suggesting to increase the file descriptors > size and we increased to 4096. But still the problem persists. We have the > Orion App Server also running on the same machine but usually during the day > when we check the open file descriptor by command: ls -l /proc/PID/fd, its > always less than 1000 combined for both Orion and Tomcat. > > > Here is the exception we see pouring in the logs once it starts: This > requires us to kill java process and restart tomcat. Our Tomcat configuration > maxThreadCount is 500 with minSpareThreads=50 in server.xml > > > SEVERE: Socket accept failed > java.net.SocketException: Too many open files > at java.net.PlainSocketImpl.socketAccept(Native Method) > at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) > at java.net.ServerSocket.implAccept(ServerSocket.java:462) > at java.net.ServerSocket.accept(ServerSocket.java:430) > at > org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61) > at > org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:352) > at java.lang.Thread.run(Thread.java:662) > > ulimit -a gives for the user where Tomcat is running. > > > open files (-n) 4096 > > > Please let me know what could be the issue here and how can i resolve this > 'Too many open files' issue. > > Thanks > -G > > > > This message may contain confidential information. If you are not the > intended recipient please inform the > sender that you have received the message in error before deleting it. > Please do not disclose, copy or distribute information in this e-mail or take > any action in reliance on its contents: > to do so is strictly prohibited and may be unlawful. > > Thank you for your co-operation. > > NHSmail is the secure email and directory service available for all NHS staff > in England and Scotland > NHSmail is approved for exchanging patient data and other sensitive > information with NHSmail and GSi recipients > NHSmail provides an email address for your career in the NHS and can be > accessed anywhere > For more information and to find out how you can switch, visit > www.connectingforhealth.nhs.uk/nhsmail > >
Re: Tomcat 6.0.35 -crossing maxThreads configured count
On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: > Hi all, > > > We have Tomcat 6.0.35 in our production Environment running on Linux, and we > have configured to use tomcatThreadPool with maxThreads=500 and > minSpareThreads=50 with default connectionTimeout(which is 6 sec). > We have two connectors (http and ssl) It has been giving some problems like > 'too many open files' or just hangs once in a while which requires a restart > to get back to normal. Have you taken any thread dumps when the server hangs? What do you see? > > > Recently i happened to check our access logs when the server hung and stopped > responding. We were printing the thread number in the logs and i have seen > the number going upto 770 (though the max is configured at 500). I was under > impression that the threads will be shared among the connectors and max it > can go to 500. Could you please explain why im seeing very high number than > configured? Is that maxThreads value per connector? It would help to see how you have your thread pool and connectors configured. Please attach your server.xml minus any comments. Also, a thread dump would be nice to confirm how many threads were actually running. Dan
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). Which would be about 16 hours. I am not sure of the meaning of connectionTimeout in this context, but that value seems to me so large as to be pretty useless for any practical timeout I can imagine. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
On 23/01/2012 14:06, Daniel Mikusa wrote: > On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: >> Hi all, >> >> >> We have Tomcat 6.0.35 in our production Environment running on Linux, and we >> have configured to use tomcatThreadPool with maxThreads=500 and >> minSpareThreads=50 with default connectionTimeout(which is 6 sec). > >> We have two connectors (http and ssl) It has been giving some problems like >> 'too many open files' or just hangs once in a while which requires a restart >> to get back to normal. > > Have you taken any thread dumps when the server hangs? What do you see? > >> >> >> Recently i happened to check our access logs when the server hung and >> stopped responding. We were printing the thread number in the logs and i >> have seen the number going upto 770 (though the max is configured at 500). I >> was under impression that the threads will be shared among the connectors >> and max it can go to 500. Could you please explain why im seeing very high >> number than configured? Is that maxThreads value per connector? > > It would help to see how you have your thread pool and connectors > configured. Please attach your server.xml minus any comments. > > Also, a thread dump would be nice to confirm how many threads were > actually running. The maxThreads in the Connector only applies to Tomcat request processing threads, it is not a limit imposed on the whole JVM. You will usually have 20-30 threads running doing various things in addition to those that your app starts. If Tomcat is at 500 + 20 then the rest are likely to be started by your application or dependencies. As Dan states, a thread dump is the way to understand this. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat 6.0.35 -crossing maxThreads configured count
André Warnier wrote: gnath wrote: Hi all, We have Tomcat 6.0.35 in our production Environment running on Linux, and we have configured to use tomcatThreadPool with maxThreads=500 and minSpareThreads=50 with default connectionTimeout(which is 6 sec). Which would be about 16 hours. I am not sure of the meaning of connectionTimeout in this context, but that value seems to me so large as to be pretty useless for any practical timeout I can imagine. After checking the docs, that value is in milliseconds, not seconds : connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). That sounds more reasonable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Cannot rid of expired Certificate ...
> From: Andrew Erskine [mailto:a.ersk...@darasoft.com] > Subject: RE: Cannot rid of expired Certificate ... > Heres my server.xml .. Only part of it, unfortunately. > port="443" minProcessors="5" maxProcessors="75" > Jan 23, 2012 10:58:37 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) > - (INFO) - Initializing Coyote HTTP/1.1 on http-80 > Jan 23, 2012 10:58:39 AM (main) (org.apache.coyote.http11.Http11BaseProtocol) > - (INFO) - Initializing Coyote HTTP/1.1 on http-443 It appears that you also have port 80 configured, you're not using APR, and ports 80 and 443 were successfully initialized. > Jan 23, 2012 10:58:53 AM (main) (org.apache.axis2.transport.http.AxisServlet) > - (WARN) - No transportReceiver for > org.apache.axis2.transport.http.AxisServletListener > found. An instance for HTTP will be configured automatically. Please update > your axis2.xml file! Looks like your Axis2 configuration is broken. > Jan 23, 2012 10:58:53 AM (HttpListener-8443-1) > (org.apache.axis2.transport.http.server.DefaultConnectionListener) > - (INFO) - Listening on port 8443 So you have Axis2 listening on 8443 - which is a commonly used HTTPS substitute port. What port are your clients trying to connect to, 443 or 8443? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot rid of expired Certificate ...
Some key authorities recently changed the default from 1024 to 2048 bit keys. On some occasions I've been forced to delete my keystore and start from scratch to make sure there are no unsuitable keys still in there. On 23/01/12 11:45 PM, "André Warnier" wrote: >Andrew Erskine wrote: >> -Original Message- >> From: André Warnier [mailto:a...@ice-sa.com] >> Sent: 23 January 2012 10:46 >> To: Tomcat Users List >> Subject: Re: Cannot rid of expired Certificate ... >> >> Andrew Erskine wrote: >> ... >>> Not sure what APR is ? >>> >> To save someone else the time : >> >> See : http://apr.apache.org/ >> >> In essence, "APR" is a software library which contains a number of >>TCP-socket-related functions which /can/ be used by software >>applications (such as Apache httpd and Tomcat), as a replacement for >>similar platform-specific functions, to provide more uniformity. >> >> In the case of Tomcat : by default, Tomcat, for its Connectors, uses >>the network-related functions provided by the Java JVM (e.g., to open a >>listening socket for a Connector). >> However, if Tomcat detects the availability of the APR library when it >>starts, it will switch to using this library instead. >> The APR implementation is supposed to be more efficient and faster. >> >> The importance of this, in the current context, is that there is a >>difference regarding SSL (HTTPS) : the standard JVM functions use the >>Java JVM's implementation of SSL, while APR functions use the OpenSSL >>library. This matters because the relevant Connector attributes are >>different in each case (and also probably where the software looks for >>"things" like keystore etc..). >> >> You can see if on your system Tomcat has found (and is using) the APR >>library or not, by examining the Tomcat logfiles : at startup, Tomcat >>will print a warning if it did not find APR. >> >> So I've deleted my certificate again and created a new certificate .. >> >> D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore >>d:\win32app\Spectrum\custom\keystore\cacerts >> Enter keystore password: >> >> Keystore type: JKS >> Keystore provider: SUN >> >> Your keystore contains 4 entries >> >> root, Oct 21, 2011, trustedCertEntry, >> Certificate fingerprint (MD5): >>BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A >> ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, >> Certificate fingerprint (MD5): >>3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 >> spectrum-92, Jan 19, 2012, PrivateKeyEntry, >> Certificate fingerprint (MD5): >>DF:BA:0D:35:8D:45:E0:79:62:6B:C7:ED:D6:B7:86:8E >> tomcatss1, Oct 21, 2011, PrivateKeyEntry, >> Certificate fingerprint (MD5): >>DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB >> >> D:\win32app\Spectrum\Java\jre\bin>keytool -delete -keystore >>d:\win32app\Spectrum\custom\keystore\cacerts -alias spectrum-92 >> Enter keystore password: >> >> D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore >>d:\win32app\Spectrum\custom\keystore\cacerts >> Enter keystore password: >> >> Keystore type: JKS >> Keystore provider: SUN >> >> Your keystore contains 3 entries >> >> root, Oct 21, 2011, trustedCertEntry, >> Certificate fingerprint (MD5): >>BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A >> ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, >> Certificate fingerprint (MD5): >>3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 >> tomcatss1, Oct 21, 2011, PrivateKeyEntry, >> Certificate fingerprint (MD5): >>DF:7D:58:4B:D1:5A:A5:AF:68:C6:5E:F4:77:7D:0D:FB >> >> D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 >>-keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore >> keytool error: java.lang.Exception: Keystore file exists, but is empty: >>d:\win32app\Spectrum\custom\keystore >> >> D:\win32app\Spectrum\Java\jre\bin>keytool -genkey -alias spectrum-92 >>-keyalg RSA -keystore d:\win32app\Spectrum\custom\keystore\cacerts >> Enter keystore password: >> What is your first and last name? >> [Unknown]: spectrum-92 >> What is the name of your organizational unit? >> [Unknown]: >> What is the name of your organization? >> [Unknown]: >> What is the name of your City or Locality? >> [Unknown]: >> What is the name of your State or Province? >> [Unknown]: >> What is the two-letter country code for this unit? >> [Unknown]: >> Is CN=spectrum-92, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, >>C=Unknown correct? >> [no]: yes >> >> Enter key password for >> (RETURN if same as keystore password): >> >> D:\win32app\Spectrum\Java\jre\bin>keytool -list -keystore >>d:\win32app\Spectrum\custom\keystore\cacerts >> Enter keystore password: >> >> Keystore type: JKS >> Keystore provider: SUN >> >> Your keystore contains 4 entries >> >> root, Oct 21, 2011, trustedCertEntry, >> Certificate fingerprint (MD5): >>BB:EA:B2:25:64:36:99:85:77:32:BA:B3:76:E6:F6:1A >> ehrp-2e2-site1, Jan 12, 2012, trustedCertEntry, >> Certificate fingerprint (MD5): >>3B:14:71:2C:15:7D:79:81:7C:D6:B7:CE:35:0E:43:80 >> spectrum-92, Jan 2
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Thanks Dan and p Sure, i will collect the thread dump once it happens again. Mean while here my server.xml content related to executor and connectors: I understand what you are saying regarding the application owned threads, but do they show in the access logs with the prefix i mentioned for tomcatThreadPool (i saw in access logs as catalina-exec-770) ? Please let me know if im missing anything or doing anything wrong in my configuration. I will check on the thread dump once i collect it. Thanks -G From: Pid To: Tomcat Users List Sent: Monday, January 23, 2012 6:12 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count On 23/01/2012 14:06, Daniel Mikusa wrote: > On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: >> Hi all, >> >> >> We have Tomcat 6.0.35 in our production Environment running on Linux, and we >> have configured to use tomcatThreadPool with maxThreads=500 and >> minSpareThreads=50 with default connectionTimeout(which is 6 sec). > >> We have two connectors (http and ssl) It has been giving some problems like >> 'too many open files' or just hangs once in a while which requires a restart >> to get back to normal. > > Have you taken any thread dumps when the server hangs? What do you see? > >> >> >> Recently i happened to check our access logs when the server hung and >> stopped responding. We were printing the thread number in the logs and i >> have seen the number going upto 770 (though the max is configured at 500). I >> was under impression that the threads will be shared among the connectors >> and max it can go to 500. Could you please explain why im seeing very high >> number than configured? Is that maxThreads value per connector? > > It would help to see how you have your thread pool and connectors > configured. Please attach your server.xml minus any comments. > > Also, a thread dump would be nice to confirm how many threads were > actually running. The maxThreads in the Connector only applies to Tomcat request processing threads, it is not a limit imposed on the whole JVM. You will usually have 20-30 threads running doing various things in addition to those that your app starts. If Tomcat is at 500 + 20 then the rest are likely to be started by your application or dependencies. As Dan states, a thread dump is the way to understand this. p -- [key:62590808]
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Hi Andre, Sorry, my mistake. you are right. i actually meant milliseconds. However i checked my configuration again and here is what i have : ( I have the http connector configured at 2 ms. and the secured one left at default 6 ms) Please let me know if im doing any mistake or missing anything here. Thanks -G From: André Warnier To: Tomcat Users List Sent: Monday, January 23, 2012 6:14 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count André Warnier wrote: > gnath wrote: >> Hi all, >> >> We have Tomcat 6.0.35 in our production Environment running on Linux, and we >> have configured to use tomcatThreadPool with maxThreads=500 and >> minSpareThreads=50 with default connectionTimeout(which is 6 sec). > > Which would be about 16 hours. I am not sure of the meaning of > connectionTimeout in this context, but that value seems to me so large as to > be pretty useless for any practical timeout I can imagine. > After checking the docs, that value is in milliseconds, not seconds : connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). That sounds more reasonable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Hi Andre, Sorry, my mistake. you are right. i actually meant milliseconds. However i checked my configuration again and here is what i have : ( I have the http connector configured at 2 ms. and the secured one left at default 6 ms) Please let me know if im doing any mistake or missing anything here. On the face of it, you are, or you are prone to typos. Assuming that when you indicate "http port" above, you mean that this is in reality some consistent specific valid port number, then at least one of them is wrong. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Please ignore my previously sent edited configuration. Here is what our configurations are without editing them : Please let me know. I appreciate your help in looking into this Thanks G From: André Warnier To: Tomcat Users List Sent: Monday, January 23, 2012 6:37 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count gnath wrote: > > Hi Andre, > Sorry, my mistake. > > you are right. i actually meant milliseconds. However i checked my > configuration again and here is what i have : ( I have the http connector > configured at 2 ms. and the secured one left at default 6 ms) > > > namePrefix="catalina-exec-" > maxThreads="500" > minSpareThreads="50"/> > > protocol="HTTP/1.1" > connectionTimeout="2" > redirectPort="https port" address="ip address"/> > > scheme="https" secure="true" > clientAuth="false" sslProtocol="TLS" address="ip address" > keystoreFile="path to cert" keystorePass="password" /> > > > Please let me know if im doing any mistake or missing anything here. > On the face of it, you are, or you are prone to typos. Assuming that when you indicate "http port" above, you mean that this is in reality some consistent specific valid port number, then at least one of them is wrong. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
On Mon, 2012-01-23 at 06:24 -0800, gnath wrote: > Thanks Dan and p > > Sure, i will collect the thread dump once it happens again. Mean while here > my server.xml content related to executor and connectors: > >namePrefix="catalina-exec-" > maxThreads="500" > minSpareThreads="50"/> > > connectionTimeout="2" >redirectPort="https port" address="ip address"/> > > scheme="https" secure="true" >clientAuth="false" sslProtocol="TLS" address="ip address" >keystoreFile="path to cert" keystorePass="password" /> > > I understand what you are saying regarding the application owned threads, but > do they show in the access logs with the prefix i mentioned for > tomcatThreadPool (i saw in access logs as catalina-exec-770) ? I do not believe that a thread with the name "catalina-exec-770" means that there are 770 active threads. It means that the thread you are looking at is number 770. The "770" is just an identifier. >From the docs for Executor: "The name prefix for each thread created by the executor. The thread name for an individual thread will be namePrefix+threadNumber". You can get a count of the threads being used by your executor with the following command: jstack | grep "catalina-exec-" | wc Dan > > Please let me know if im missing anything or doing anything wrong in my > configuration. > I will check on the thread dump once i collect it. > > Thanks > -G > > > > > From: Pid > To: Tomcat Users List > Sent: Monday, January 23, 2012 6:12 AM > Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count > > On 23/01/2012 14:06, Daniel Mikusa wrote: > > On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: > >> Hi all, > >> > >> > >> We have Tomcat 6.0.35 in our production Environment running on Linux, and > >> we have configured to use tomcatThreadPool with maxThreads=500 and > >> minSpareThreads=50 with default connectionTimeout(which is 6 sec). > > > >> We have two connectors (http and ssl) It has been giving some problems > >> like 'too many open files' or just hangs once in a while which requires a > >> restart to get back to normal. > > > > Have you taken any thread dumps when the server hangs? What do you see? > > > >> > >> > >> Recently i happened to check our access logs when the server hung and > >> stopped responding. We were printing the thread number in the logs and i > >> have seen the number going upto 770 (though the max is configured at 500). > >> I was under impression that the threads will be shared among the > >> connectors and max it can go to 500. Could you please explain why im > >> seeing very high number than configured? Is that maxThreads value per > >> connector? > > > > It would help to see how you have your thread pool and connectors > > configured. Please attach your server.xml minus any comments. > > > > Also, a thread dump would be nice to confirm how many threads were > > actually running. > > The maxThreads in the Connector only applies to Tomcat request > processing threads, it is not a limit imposed on the whole JVM. > > You will usually have 20-30 threads running doing various things in > addition to those that your app starts. > > If Tomcat is at 500 + 20 then the rest are likely to be started by your > application or dependencies. As Dan states, a thread dump is the way to > understand this. > > > p > > > > > > -- > > [key:62590808]
Re: Tomcat 6.0.35 -crossing maxThreads configured count
Sure i will keep monitoring the Thread count as you said using jstack and keep you posted once the server hangs again. Thanks -G From: Daniel Mikusa To: Tomcat Users List ; gnath Sent: Monday, January 23, 2012 6:44 AM Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count On Mon, 2012-01-23 at 06:24 -0800, gnath wrote: > Thanks Dan and p > > Sure, i will collect the thread dump once it happens again. Mean while here > my server.xml content related to executor and connectors: > > namePrefix="catalina-exec-" > maxThreads="500" > minSpareThreads="50"/> > > connectionTimeout="2" > redirectPort="https port" address="ip address"/> > > scheme="https" secure="true" > clientAuth="false" sslProtocol="TLS" address="ip address" > keystoreFile="path to cert" keystorePass="password" /> > > I understand what you are saying regarding the application owned threads, but > do they show in the access logs with the prefix i mentioned for > tomcatThreadPool (i saw in access logs as catalina-exec-770) ? I do not believe that a thread with the name "catalina-exec-770" means that there are 770 active threads. It means that the thread you are looking at is number 770. The "770" is just an identifier. >From the docs for Executor: "The name prefix for each thread created by the executor. The thread name for an individual thread will be namePrefix+threadNumber". You can get a count of the threads being used by your executor with the following command: jstack | grep "catalina-exec-" | wc Dan > > Please let me know if im missing anything or doing anything wrong in my > configuration. > I will check on the thread dump once i collect it. > > Thanks > -G > > > > > From: Pid > To: Tomcat Users List > Sent: Monday, January 23, 2012 6:12 AM > Subject: Re: Tomcat 6.0.35 -crossing maxThreads configured count > > On 23/01/2012 14:06, Daniel Mikusa wrote: > > On Mon, 2012-01-23 at 05:44 -0800, gnath wrote: > >> Hi all, > >> > >> > >> We have Tomcat 6.0.35 in our production Environment running on Linux, and > >> we have configured to use tomcatThreadPool with maxThreads=500 and > >> minSpareThreads=50 with default connectionTimeout(which is 6 sec). > > > >> We have two connectors (http and ssl) It has been giving some problems > >> like 'too many open files' or just hangs once in a while which requires a > >> restart to get back to normal. > > > > Have you taken any thread dumps when the server hangs? What do you see? > > > >> > >> > >> Recently i happened to check our access logs when the server hung and > >> stopped responding. We were printing the thread number in the logs and i > >> have seen the number going upto 770 (though the max is configured at 500). > >> I was under impression that the threads will be shared among the > >> connectors and max it can go to 500. Could you please explain why im > >> seeing very high number than configured? Is that maxThreads value per > >> connector? > > > > It would help to see how you have your thread pool and connectors > > configured. Please attach your server.xml minus any comments. > > > > Also, a thread dump would be nice to confirm how many threads were > > actually running. > > The maxThreads in the Connector only applies to Tomcat request > processing threads, it is not a limit imposed on the whole JVM. > > You will usually have 20-30 threads running doing various things in > addition to those that your app starts. > > If Tomcat is at 500 + 20 then the rest are likely to be started by your > application or dependencies. As Dan states, a thread dump is the way to > understand this. > > > p > > > > > > -- > > [key:62590808]
Restarting tomcat 7.0.23 on MAC OS X 10.6
I hope somebody can help me. I have a test-server on my macbook pro and it takes forever to restart the server do anyone have a clue to whats happening. I have run the configuration just fine on a windows laptop. It also takes forever with the default configuration. I just the following guide http://wolfpaulus.com/journal/mac/tomcat7 -- *Oliver Billing* *Developer* watAgame ApS Kigkurren 8D, 1st 2300 Copenhagen S Denmark office +45 3536 4110 direct +45 8833 6288 mobile +45 2087 7341 o...@watagame.com www.goSupermodel.com www.watAgame.com
Re: CVE-2012-0022 details
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 1/22/12 5:08 PM, ma...@apache.org wrote: > Christopher Schultz wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> David, >> >> On 1/21/12 3:02 AM, David Jorm wrote: >>> Based on reading the advisory and Tomcat patch code, it seems >>> to me that the issue is simply slow processing when a very >>> large number of parameters is received with a request. >> >> The parameter names must have colliding hash code values in order >> to exercise this particular vulnerability. Otherwise, large >> numbers of request parameters is merely a potential memory >> exhaustion vulnerability (which is a different issue). > > No, no, no. That is completely wrong. CVE-2012-0022 is solely about > the number of parameters and NOTHING TO DO WITH HASH COLLISIONS. Sorry, the last time I looked-up CVE-2012-0022 it said that it was just a placeholder which I assumed was being held in reserve for the hash-collision bug. I see now that the data has been updated and it even includes a note that it's NOT CVE-2011-4858. Sorry for the noise. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8dgCcACgkQ9CaO5/Lv0PB2LQCdGnDpbrD6zsjpeaQY6RdcCmgQ xHoAnRvInr0xIs7srQuXsJOdL+aggSxN =eJc3 -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-SocketException: Too many open files issue with
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 1/22/12 6:18 PM, gnath wrote: > We have 2 connectors (one for http and another for https) using > the tomcatThreadPool. I have the connectionTimeout="2" for > http connector. However i was told that our https connector might > not be used by the app as our loadbalancer is handling all the > https traffic and just sending them to http connector. You might want to disable that HTTPS connector, but it's probably not hurting you at all in this case -- just a bit of wasted resources. If you are sharing a thread pool then there is no negative impact on the number of threads and/or open files that you have to deal with, here. > the ulimit settings were increased from default 1024 to 4096 by > our admin. not sure how he did that, but i see the count as 4096 > when i do ulimit -a. Well, if your admin says it's right, I suppose it's right. > for ulimit -n i see its 'unlimited'. That's good. > for cat /proc/PID/limits, i get the following response: > > Limit Soft Limit Hard Limit > Units Max cpu time unlimitedunlimited > seconds Max file size unlimitedunlimited > bytes Max data size unlimitedunlimited > bytes Max stack size10485760 unlimited > bytes Max core file size0unlimited > bytes Max resident set unlimitedunlimited > bytes Max processes unlimitedunlimited > processes Max open files4096 4096 > files Max locked memory 3276832768 > bytes Max address space unlimitedunlimited > bytes Max file locksunlimitedunlimited > locks Max pending signals 202752 202752 > signals Max msgqueue size 819200 819200 > bytes Max nice priority 00 > Max realtime priority 00 Those all look good to me. > This morning Tomcat hung again but this time it dint say 'too many > open files' in logs but i only see this below in catalina.out: > > org.apache.tomcat.util.http.Parameters processParameters INFO: > Invalid chunk starting at byte [0] and ending at byte [0] with a > value of [null] ignored Jorg.apache.tomcat.util.http.Parameters > processParameters INFO: Invalid chunk starting at byte [0] and > ending at byte [0] with a value of [null] ignored Hmm... > When it hung(java process is still up), i ran few commands like > lsof by PID and couple others. Next time, take a thread dump as well. The fact that Tomcat hung up without an OS problem (like Too Many Open Files) is probably not good. If this happens again with an apparent hang with no stack traces in the logs, take a thread dump and post it back here under a different subject. > here is what i got: > > lsof -p PID| wc -l 1342 > > lsof | wc -l 4520 > > lsof -u USER| wc -l 1953 Hmm I wonder if you are hitting a *user* or even *system* limit of some kind (though a *NIX system with a hard limit of ~4500 file descriptors seems entirely unreasonable). I also wonder how many /processes/ and/or /threads/ you have running at once. > After i kill java process the lsof for pid returned obviously to > zero Of course. > Is there any chance that the tomcat is ignoring the ulimit? Those limits are not self-imposed: the OS imposes those limits. Tomcat doesn't even know it's own ulimit (of any kind), so it will simply consume whatever resources you have configured it to use, and if it hits a limit, the JVM will experience some kind of OS-related error. > , some people on web were saying something about setting this in > catalina.sh. Setting what? ulimit? I'd do it in setenv.sh because that's a more appropriate place for that kind of thing. I'm also interested in what the Internet has to say about what setting(s) to use. > Please help with my ongoing issue.. its getting very hard to > monitor the logs every minute and restarting whenever it hangs with > these kind of issues. I very much appreciate your help in this. Did this just start happening recently? Perhaps with an upgrade of some component? If you think this might actually be related to the number of file handles being used by your thread pool, you might want to reduce the maximum number of threads for that thread pool: a slightly less responsive site is better than one that goes down all the time because of hard resource limits. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8dghAACgkQ9CaO5/Lv0PCmKQCfUaYfeoSkTRDKBppR4ZGFTWgI 8dEAoKgwy1BcKO6bC8nbbLWd6hn0a38N =TZCu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additi
Re: Restarting tomcat 7.0.23 on MAC OS X 10.6
On Mon, 2012-01-23 at 07:41 -0800, Oliver Due Billing wrote: > I hope somebody can help me. > > I have a test-server on my macbook pro and it takes forever to restart the > server do anyone have a clue to whats happening. What is the exact version of Java & Tomcat? Also, how many applications do you have deployed? > I have run the configuration just fine on a windows laptop. Can we assume that these are the exact same installations? i.e. same version of Java and Tomcat? Also, the exact same configuration files (to the character)? > > It also takes forever with the default configuration. So, you unzip Tomcat, run "bin/start.sh" and it takes forever to start? No custom applications deployed and no changes to any configuration files? Dan
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Please ignore my previously sent edited configuration. Here is what our configurations are without editing them : Please let me know. I appreciate your help in looking into this I have not gone back to your first message, but from the subject I guess that your concern is that you think that there are a lot of threads active in Tomcat, as compared to the number of HTTP requests that your server is receiving. The following does not in any way mean that you should not follow the other advices, and verify your assumptions, using the appropriate tools. But you may also want to have a look at the Connector's keep-alive setting. connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). keepAliveTimeout The number of milliseconds this Connector will wait for another HTTP request before closing the connection. The default value is to use the value that has been set for the connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout. In your configuration, you do not use an explicit keepAliveTimeout attribute, so it defaults to the connectionTimeout, which is 20 seconds. Imagine that your server receives requests for pages, at the rate of 10 per second. And that each page contains 3 embedded thumbnail images. So after the first request for the page, the browser is going to issue 3 more requests for the embedded images. By default, the keep-alive is active, which means that this all happens over the same HTTP (or HTTPS) connection; and since it all happens over the same established connection, it will also be processed by the same Tomcat thread. Which is all basically all A Good Thing, because it avoids having to tear down and rebuild connections and threads for each request. Processing the 4 consecutive requests of the browser is likely to take only a fraction of a second altogether. After these 4 requests are served, the keepAliveTimeout starts running, and with your current settings it does so for 20 seconds. During these 20 seconds, the thread which has processed the 4 requests keeps waiting, in case the browser has any more requests to send over the same connection (which it probably has not, because the user is considering his next move). 1/10th of a second after the first request, another browser also sends a request. Since the first thread is still busy, a new one is allocated. After a fraction of a second, that one goes in keepAliveTimeout. And so on. So all in all, this scenario is allocating new threads at the rythm of 10 per second; and it is only after the first 20 seconds have gone by, that the timeout of the first thread expires, that it can close its connection, and return to the pool to process another browser request. By that time, according to the above scenario, you have about 200 threads waiting in their keep-alive status, and basically not doing anything. I am not saying that your scenario matches the above, and only you can determine that. But it could explain a high number of threads apparently idle. So if those idle threads bother you, it may be worth trying an explicit lower keepAliveTimeout (e.g. 5 s), and monitor the impact. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
gnath wrote: Please ignore my previously sent edited configuration. Here is what our configurations are without editing them : Please let me know. I appreciate your help in looking into this I have not gone back to your first message, but from the subject I guess that your concern is that you think that there are a lot of threads active in Tomcat, as compared to the number of HTTP requests that your server is receiving. The following does not in any way mean that you should not follow the other advices, and verify your assumptions, using the appropriate tools. But you may also want to have a look at the Connector's keep-alive setting. connectionTimeout The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds). keepAliveTimeout The number of milliseconds this Connector will wait for another HTTP request before closing the connection. The default value is to use the value that has been set for the connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout. In your configuration, you do not use an explicit keepAliveTimeout attribute, so it defaults to the connectionTimeout, which is 20 seconds. Imagine that your server receives requests for pages, at the rate of 10 per second. And that each page contains 3 embedded thumbnail images. So after the first request for the page, the browser is going to issue 3 more requests for the embedded images. By default, the keep-alive is active, which means that this all happens over the same HTTP (or HTTPS) connection; and since it all happens over the same established connection, it will also be processed by the same Tomcat thread. Which is all basically all A Good Thing, because it avoids having to tear down and rebuild connections and threads for each request. Processing the 4 consecutive requests of the browser is likely to take only a fraction of a second altogether. After these 4 requests are served, the keepAliveTimeout starts running, and with your current settings it does so for 20 seconds. During these 20 seconds, the thread which has processed the 4 requests keeps waiting, in case the browser has any more requests to send over the same connection (which it probably has not, because the user is considering his next move). 1/10th of a second after the first request, another browser also sends a request. Since the first thread is still busy, a new one is allocated. After a fraction of a second, that one goes in keepAliveTimeout. And so on. So all in all, this scenario is allocating new threads at the rythm of 10 per second; and it is only after the first 20 seconds have gone by, that the timeout of the first thread expires, that it can close its connection, and return to the pool to process another browser request. By that time, according to the above scenario, you have about 200 threads waiting in their keep-alive status, and basically not doing anything. I am not saying that your scenario matches the above, and only you can determine that. But it could explain a high number of threads apparently idle. So if those idle threads bother you, it may be worth trying an explicit lower keepAliveTimeout (e.g. 5 s), and monitor the impact. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restarting tomcat 7.0.23 on MAC OS X 10.6
> From: Oliver Due Billing [mailto:o...@watagame.com] > Subject: Restarting tomcat 7.0.23 on MAC OS X 10.6 > I have a test-server on my macbook pro and it takes forever to > restart the server do anyone have a clue to whats happening. It may be collecting entropy. Take a thread dump, and see what the JVM is doing during the pause. You can try setting -Djava.security.egd=file:/dev/./urandom as a system property. Note that the apparently extra "/." is required to trick the JVM into using the alternate random byte source. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . crash-on-takeoff)
We're now trying to bring up Tomcat 7 on a V5R4 AS/400, after successfully doing so on V6 and V7 boxes. They have Java 6 installed, and I'm told that they installed some PTFs over the weekend, but it's still crashing on takeoff. In catalina.sh, we have: # Java 6 settings if needed export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre export -s CATALINA_HOME=/wintouch/tomcat export -s JAVA_OPTS="-Dos400.awt.native=true -Djava.awt.headless=true -Djava.version=1.6 -Xms256m -Xmx512m" # OS specific support. $var _must_ be set to either true or false. cygwin=false darwin=false os400=true case "`uname`" in CYGWIN*) cygwin=true;; Darwin*) darwin=true;; OS400*) os400=true;; esac and there is definitely a "java" in the /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/bin directory, and so far as I'm aware, all the JARs are present in the right subdirectories of /wintouch/tomcat, but in catalina.out, I get: Attaching Java program to /QIBM/ProdData/Java400/jdk6/lib/charsets.jar. Attaching Java program to /QIBM/ProdData/Java400/jdk6/lib/resources.jar. Attaching Java program to /QIBM/ProdData/Java400/jdk6/lib/rt.jar. eval: 001-0014 Command /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/bin/java not found. java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader.findClass(URLClassLoader.java:432) at java.lang.ClassLoader.loadClass(ClassLoader.java:642) at java.lang.ClassLoader.loadClass(ClassLoader.java:608) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:236) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) When I delete catalina.out and try again, I get the same, only starting from the ClassNotFoundException. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
Initially I thought that my RootJDBCRealm might be the problem, but how can that be? RootJDBCRealm extends Tomcat's own JDBCRealm. It overrides authenticate to call super.authenticate and if there are 3 failures (in that super.authenticate returns null), then it locks out the user. So could the user of RootJDBCRealm still be a problem? Thanks. --- On Mon, 1/23/12, Mark Thomas wrote: > From: Mark Thomas > Subject: Re: Connection.close() has already been called during login > To: "Tomcat Users List" > Date: Monday, January 23, 2012, 12:49 AM > On 23/01/2012 03:49, removeps-c...@yahoo.com > wrote: > > Am running Tomcat 7 and see this in the logs: > > > > SEVERE: Exception performing authentication > > > com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: > Connection.close() has already been called. Invalid > operation in this state. > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > at > java.lang.reflect.Constructor.newInstance(Constructor.java:513) > > at > com.mysql.jdbc.Util.handleNewInstance(Util.java:406) > > at > com.mysql.jdbc.Util.getInstance(Util.java:381) > > at > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984) > > at > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) > > at > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) > > at > com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018) > > at > com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512) > > at > org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579) > > at > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408) > > at > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355) > > at > pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71) > > The above line is key. You are not using Tomcat's > JDBCRealm. > > > at > org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295) > > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450) > > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) > > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) > > at > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > at > java.lang.Thread.run(Thread.java:662) > > > > > > could the reason be ROOT/META-INF/context.xml which > says > > > > > > > > className="pacific.tomcat.RootJDBCRealm" > > > driverName="pacific.driver.PacificMysqlDriver" > > > connectionName="auth" connectionPassword="..." > > > connectionURL="pacific@jdbc:mysql://localhost:3306" > > userTable="user" > userNameCol="username" userCredCol="password" > > > userRoleTable="user_role" roleNameCol="rolename" > > digest="SHA1"/> > > > > That is, should I be using a datasource realm > instead? > > Yes. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
>2012/1/23 : > Initially I thought that my RootJDBCRealm might be the problem, but how can > that be? RootJDBCRealm extends Tomcat's own JDBCRealm. It >overrides > authenticate to call super.authenticate and if there are 3 failures (in that > super.authenticate returns null), then it locks out the user. So could >the > user of RootJDBCRealm still be a problem? Thanks. >From Tomcat 7 docs: "The JDBCRealm is not recommended for production use as it is single threaded for all authentication and authorization options. Use the DataSourceRealm instead. The UserDatabaseRealm is not intended for large-scale installations. It is intended for small-scale, relatively static environments." - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
On Mon, 2012-01-23 at 10:21 -0800, removeps-c...@yahoo.com wrote: > Initially I thought that my RootJDBCRealm might be the problem, but how can > that be? > RootJDBCRealm extends Tomcat's own JDBCRealm. It overrides authenticate to > call super.authenticate and if there are 3 failures (in that > super.authenticate returns null), then it locks out the user. Sounds a lot like the LockOutRealm. https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#LockOutRealm Any reason you opted not to use it? Dan > So could the user of RootJDBCRealm still be a problem? Thanks. > > --- On Mon, 1/23/12, Mark Thomas wrote: > > > From: Mark Thomas > > Subject: Re: Connection.close() has already been called during login > > To: "Tomcat Users List" > > Date: Monday, January 23, 2012, 12:49 AM > > On 23/01/2012 03:49, removeps-c...@yahoo.com > > wrote: > > > Am running Tomcat 7 and see this in the logs: > > > > > > SEVERE: Exception performing authentication > > > > > com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: > > Connection.close() has already been called. Invalid > > operation in this state. > > > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > Method) > > > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > > at > > java.lang.reflect.Constructor.newInstance(Constructor.java:513) > > > at > > com.mysql.jdbc.Util.handleNewInstance(Util.java:406) > > > at > > com.mysql.jdbc.Util.getInstance(Util.java:381) > > > at > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984) > > > at > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) > > > at > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) > > > at > > com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018) > > > at > > com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512) > > > at > > org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579) > > > at > > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408) > > > at > > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355) > > > at > > pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71) > > > > The above line is key. You are not using Tomcat's > > JDBCRealm. > > > > > at > > org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295) > > > at > > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450) > > > at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > > > at > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > > > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > > > at > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > > > at > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) > > > at > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) > > > at > > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773) > > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > > at > > java.lang.Thread.run(Thread.java:662) > > > > > > > > > could the reason be ROOT/META-INF/context.xml which > > says > > > > > > > > > > > >> className="pacific.tomcat.RootJDBCRealm" > > > > > driverName="pacific.driver.PacificMysqlDriver" > > > > > connectionName="auth" connectionPassword="..." > > > > > connectionURL="pacific@jdbc:mysql://localhost:3306" > > > userTable="user" > > userNameCol="username" userCredCol="password" > > > > > userRoleTable="user_role" roleNameCol="rolename" > > > digest="SHA1"/> > > > > > > That is, should I be using a datasource realm > > instead? > > > > Yes. > > > > Mark > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
RE: Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . crash-on-takeoff)
> From: James Lampert [mailto:jam...@touchtonecorp.com] > Subject: Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . > crash-on-takeoff) > In catalina.sh, we have: > > # Java 6 settings if needed > > > > export -s JAVA_HOME=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre > > > > export -s CATALINA_HOME=/wintouch/tomcat > > > > export -s JAVA_OPTS="-Dos400.awt.native=true -Djava.awt.headless=true > > -Djava.version=1.6 -Xms256m -Xmx512m" It's considered bad form to modify catalina.sh; create a setenv.sh script and put your environment changes there. > # OS specific support. $var _must_ be set to either true or false. > > os400=true Why was it necessary to force os400 to true? > eval: 001-0014 Command > /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/bin/java not found. That's not a good sign, but it looks like some java executable was found. What prints the above message with the odd prefix? > java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina > The above would indicate that setclasspath.sh failed. One thing you didn't tell us was exactly how you start Tomcat. Have you tried starting Tomcat from a command prompt so you can see the display of the derived variables, such as CLASSPATH? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.35 -crossing maxThreads configured count
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G, On 1/23/12 8:44 AM, gnath wrote: > Recently i happened to check our access logs when the server hung > and stopped responding. We were printing the thread number in the > logs and i have seen the number going upto 770 (though the max is > configured at 500). I was under impression that the threads will > be shared among the connectors and max it can go to 500. Could you > please explain why im seeing very high number than configured? Is > that maxThreads value per connector? Since you are using a thread pool, threads are probably expiring after a certain period of time. New threads get numbers that increase constantly over time, so you will see this number (in the name of the thread) increase over maxThreads. It's nothing to worry about. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8dtFAACgkQ9CaO5/Lv0PCdFwCdFF3NwnElEm6WaNAO7MOB3B5b LIYAoL9dfu+mULYAlt0oSDgUoV0oFZ2R =GkNd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To whom it may concern, On 1/23/12 1:21 PM, removeps-c...@yahoo.com wrote: > Initially I thought that my RootJDBCRealm might be the problem, > but how can that be? RootJDBCRealm extends Tomcat's own JDBCRealm. > It overrides authenticate to call super.authenticate and if there > are 3 failures (in that super.authenticate returns null), then it > locks out the user. So could the user of RootJDBCRealm still be a > problem? It obviously depends upon what code is in RootJCBDRealm. Care you share? As someone else already pointed out, you might want to look at LockOutRealm. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8duqYACgkQ9CaO5/Lv0PCkAwCfdhqhvv/WR81eJn/GtlZf2ary wh8An17S8BA/zToMQjLYmHthGBtJRxJy =LfEC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
--- On Mon, 1/23/12, Daniel Mikusa wrote: > From: Daniel Mikusa > Subject: Re: Connection.close() has already been called during login > To: "Tomcat Users List" > Date: Monday, January 23, 2012, 10:55 AM > On Mon, 2012-01-23 at 10:21 -0800, removeps-c...@yahoo.com > wrote: > > Initially I thought that my RootJDBCRealm might be the > problem, but how can that be? > > > RootJDBCRealm extends Tomcat's own JDBCRealm. It > overrides authenticate to call super.authenticate and if > there are 3 failures (in that super.authenticate returns > null), then it locks out the user. > > Sounds a lot like the LockOutRealm. > > https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#LockOutRealm > > Any reason you opted not to use it? Sorry, I did not know about this class. Will this class work if you have many Tomcats on different machines (possibly load balancing) so regardless of which exact machine the user is directed to, lock realm will know the number of failed login attempts on other machines? > > Dan > > > So could the user of RootJDBCRealm > still be a problem? Thanks. > > > > --- On Mon, 1/23/12, Mark Thomas > wrote: > > > > > From: Mark Thomas > > > Subject: Re: Connection.close() has already been > called during login > > > To: "Tomcat Users List" > > > Date: Monday, January 23, 2012, 12:49 AM > > > On 23/01/2012 03:49, removeps-c...@yahoo.com > > > wrote: > > > > Am running Tomcat 7 and see this in the > logs: > > > > > > > > SEVERE: Exception performing authentication > > > > > > > > com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: > > > Connection.close() has already been called. > Invalid > > > operation in this state. > > > > at > > > > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > > Method) > > > > at > > > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > > > > at > > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > > > > at > > > > java.lang.reflect.Constructor.newInstance(Constructor.java:513) > > > > at > > > > com.mysql.jdbc.Util.handleNewInstance(Util.java:406) > > > > at > > > com.mysql.jdbc.Util.getInstance(Util.java:381) > > > > at > > > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984) > > > > at > > > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) > > > > at > > > > com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) > > > > at > > > > com.mysql.jdbc.ConnectionImpl.getMutex(ConnectionImpl.java:3018) > > > > at > > > > com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1512) > > > > at > > > > org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:579) > > > > at > > > > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:408) > > > > at > > > > org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:355) > > > > at > > > > pacific.tomcat.RootJDBCRealm.authenticate(SourceFile:71) > > > > > > The above line is key. You are not using > Tomcat's > > > JDBCRealm. > > > > > > > at > > > > org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:295) > > > > at > > > > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:450) > > > > at > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > > > > at > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > > > > at > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > > > > at > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > > > > at > > > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) > > > > at > > > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) > > > > at > > > > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1773) > > > > at > > > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > > > > at > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > > > at > > > java.lang.Thread.run(Thread.java:662) > > > > > > > > > > > > could the reason be > ROOT/META-INF/context.xml which > > > says > > > > > > > > > > > > > > > > > > className="pacific.tomcat.RootJDBCRealm" > > > > > > > driverName="pacific.driver.PacificMysqlDriver" > > > > > > > connectionName="auth" connectionPassword="..." > > > > > > > > connectionURL="pacific@jdbc:mysql://localhost:3306" > > > > > userTable="user" > > > userNameCol="username" userCredCol="password" > > > > > > > userRoleTable="user_role" roleNameCol="rolename" > > > > > digest="SHA1"/> > > > > > > > >
Re: Connection.close() has already been called during login
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To whom it may concern, On 1/23/12 2:54 PM, removeps-c...@yahoo.com wrote: > Sorry, I did not know about [LockOutRealm]. Will this class work > if you have many Tomcats on different machines (possibly load > balancing) so regardless of which exact machine the user is > directed to, lock realm will know the number of failed login > attempts on other machines? No, neither this nor any other Tomcat realms are cluster-aware. If you want to track authentication failures across a cluster, you could subclass LockOutRealm and override these methods: - - isLocked - - unlock - - registerAuthFailure This will allow you to handle the cluster-sync behavior separately from the authentication behavior which this class already handles. I'm interested in seeing what you come up with for communicating with the rest of the cluster. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8dv+4ACgkQ9CaO5/Lv0PDRnwCgvZFJvYXbU8Gwec6y430aD/rz Kk4An2C5ZwXZf4NEaS31A5CWngqGxI9F =zDyr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: parallel webapp initialization
On Tue, Oct 11, 2011 at 6:42 AM, Mark Thomas wrote: > I have added a patch based on the previous patches that adds: > - threaded start/stop for Contexts > - threaded start/stop for Hosts > - threaded deployment > > Control over the number of threads is via server.xml and/or JMX. This > can be changed dynamically. > > Review, feedback, testing etc. welcome. > > With 4 threads rather than the current 1 (on a 8-core machine), I saw a > 20-25% improvement in start time with a large number of Contexts that > all start quickly. I'd expect to see better results in situations where > 1 few Contexts start slowly but most are quick. Resurrecting an old thread, but I've started using this in Tomcat 7.0.25 with good results - have a Tomcat instance used for testing with a couple dozen contexts that take a while to load each, but with startStopThreads bumped up it reduces startup time from 60 seconds to 20 seconds using all available CPU cores. Very helpful! Thanks! -Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
My code does not talk to another cluster as I have a single Tomcat only, but just wondering how one would scale. Maybe the strategy to handle clusters is to write information, such as the list of the users to the number of times they have logged in in the last hour, into a location shared by all machines. In my code below the code is stored in failedAttempts which is a Map where FailedAttempt represents the number of times the user has logged in in the last hour or whatever. It is in-memory, which is fine for one Tomcat. But we could move this Map into a file that is on a mounted drive available from all Tomcat machines, or we could store it in the database. Either way we have to synchronize writes to the file or database, and I think database does this automatically, and maybe FileLock will do the job for the files. But anyway, it sounds complicated. As for my my authenticate it was as follows, although I don't see this should cause the failure in the subject of this email -- "Connection.close() has already been called during login": public Principal authenticate(String username, String credentials) { threadUserLockedOut.remove(); long curTime = System.currentTimeMillis(); FailedAttempt failedAttempt = failedAttempts.get(username); if (failedAttempt != null && failedAttempt.checkFailedAttemptsReached(curTime)) { threadUserLockedOut.set(Boolean.TRUE); return null; } Principal result = super.authenticate(username, credentials); if (result == null) { if (failedAttempt != null) { failedAttempt.incNumFailedAttempts(); if (failedAttempt.maxFailedAttemptsReached()) { failedAttempt.setFirstFailedTime(curTime); logger.warn("User '" + username + "' is locked out after " + MAX_FAILED_ATTEMPTS + " failed attempts"); threadUserLockedOut.set(Boolean.TRUE); return null; } } else { failedAttempt = new FailedAttempt(curTime); failedAttempts.put(username, failedAttempt); } } else { if (failedAttempt != null) { failedAttempts.remove(username); } } return result; } --- On Mon, 1/23/12, Christopher Schultz wrote: > From: Christopher Schultz > Subject: Re: Connection.close() has already been called during login > To: "Tomcat Users List" > Date: Monday, January 23, 2012, 12:15 PM > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > To whom it may concern, > > On 1/23/12 2:54 PM, removeps-c...@yahoo.com > wrote: > > Sorry, I did not know about [LockOutRealm]. Will > this class work > > if you have many Tomcats on different machines > (possibly load > > balancing) so regardless of which exact machine the > user is > > directed to, lock realm will know the number of failed > login > > attempts on other machines? > > No, neither this nor any other Tomcat realms are > cluster-aware. > > If you want to track authentication failures across a > cluster, you > could subclass LockOutRealm and override these methods: > > - - isLocked > - - unlock > - - registerAuthFailure > > This will allow you to handle the cluster-sync behavior > separately > from the authentication behavior which this class already > handles. > > I'm interested in seeing what you come up with for > communicating with > the rest of the cluster. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8dv+4ACgkQ9CaO5/Lv0PDRnwCgvZFJvYXbU8Gwec6y430aD/rz > Kk4An2C5ZwXZf4NEaS31A5CWngqGxI9F > =zDyr > -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: Connection.close() has already been called during login
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To whom it may concern, On 1/23/12 4:20 PM, removeps-c...@yahoo.com wrote: > My code does not talk to another cluster as I have a single Tomcat > only, but just wondering how one would scale. Me too. > Maybe the strategy to handle clusters is to write information, such > as the list of the users to the number of times they have logged > in in the last hour, into a location shared by all machines. That sounds fairly straightforward. > In my code below the code is stored in failedAttempts which is a > Map where FailedAttempt > represents the number of times the user has logged in in the last > hour or whatever. It is in-memory, which is fine for one Tomcat. Right. This is how Tomcat does things in its own LockOutRealm. Take a look at the code. It works with all realm types (see the code for the different authenticate() methods it implements). > But we could move this Map into a file that is on a mounted drive > available from all Tomcat machines, or we could store it in the > database. Either way we have to synchronize writes to the file or > database, and I think database does this automatically, and maybe > FileLock will do the job for the files. But anyway, it sounds > complicated. memcached. Cassandra. Whatever. > As for my my authenticate it was as follows, although I don't see > this should cause the failure in the subject of this email -- > "Connection.close() has already been called during login": Yup, it certainly doesn't look like your code does anything with the superclass's Connection. > public Principal authenticate(String username, String credentials) > { threadUserLockedOut.remove(); Why in the world are you using a ThreadLocal in here? It makes me wonder what other odd things you are doing in your Realm (or anywhere else for that matter). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8d4moACgkQ9CaO5/Lv0PDL2QCeOM9Q4e1FTa/oQv3IuUtBqzQJ 5G8AoJo9XrkNoz29zLAcNBeDir7QdYM9 =Elm7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Critical Problem Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lau, On 1/18/12 6:52 PM, Lau Eng Huat wrote: > I have a strange problem. I have deleted a servlet from the project > in netbeans but the uncompile source code still says the file > exist. I'll bite. What does "uncomple source code" mean. Did you delete the .class file or the .java file or both? > I have deleted the WEB-INF\classes and did a clean and build. > Still the problems exists. Does anybody knows how to solved this > problem ??? It's not really clear what the problem is. If you think something is really out-of-sync, you should: 1. Stop Tomcat 2. Completely remove your WAR file or exploded WAR Directory 3. Completely remove your CATALINA_BASE/work directory and its contents 4. Re-build your webapp cleanly and re-deploy it 5. Start Tomcat > Jan 19, 2012 7:46:37 AM org.apache.catalina.core.ApplicationContext > log INFO: Marking servlet AdminCardServletLogin as unavailable Jan > 19, 2012 7:46:37 AM org.apache.catalina.core.StandardWrapperValve > invoke SEVERE: Allocate exception for servlet ServletABC > java.lang.RuntimeException: Uncompilable source code - > AllReadyDeletedServlet If, after the above steps, you are still having problems, please post your entire catalina.out file back with your next post. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8d5CUACgkQ9CaO5/Lv0PAvLwCgw2ljN97KjA9XXiJLqdRukhag 1DIAnjTYUgxkFVcMF1QOJRM8XFEGjLjK =OTs2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem bringing up SSL with a CA certificate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James, On 1/18/12 12:37 PM, James Lampert wrote: > So far, I've had complete success using self-signed certificates, > both here and on the customer box, once I found out that the CN > needs to match the domain name. ;) > But now, we're trying to get the customer box up on a CA-signed > certificate, and Tomcat doesn't like it. (Given that we haven't > done it on our own box, it's kind of a case of the blind leading > the blind.) We had our contact with the customer follow the > procedure given on > > http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Importing_the_Certificate > > > > and I put the resulting keystore into service, started Tomcat, and > got this in logs/catalina.out: > >> SEVERE: Failed to initialize end point associated with >> ProtocolHandler ["http-bio-443"] Throwable occurred: >> java.io.IOException: Alias name tomcat does not identify a key >> entry at Did you also put your server's key into the keystore? > If I list the keystore, I get: >> Keystore type: jks >> Keystore provider: IBMJCE >> >> >> Your keystore contains 2 entries >> >> >> root, Jan 18, 2012, trustedCertEntry, >> Certificate fingerprint (MD5): >> D6:6A:92:1C:83:BF:A2:AE:6F:99:5B:44:E7:C2:AB:2A tomcat, Jan 18, >> 2012, trustedCertEntry, >> Certificate fingerprint (MD5): >> 55:D7:4D:D4:83:01:D6:E0:EB:A4:F3:9A:06:BD:87:38 It looks like you only have certificates. Did you forget to import the key into the keystore? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8d5S0ACgkQ9CaO5/Lv0PC7oACdHek6Dxn2r0p2TXz7w9IxYJv8 EecAoI45tZqdrBsTZGII759VyURQAsFL =beQr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem bringing up SSL with a CA certificate
Christopher Schultz wrote: Did you also put your server's key into the keystore? It seems that when the customer rep jumped the gun and submitted a CSR to Thawte before we even had Tomcat running on a self-signed certificate, he did so using IBM DCM, whose keystores are incompatible with Keytool, and presumably also with Tomcat. Fortunately, there's still a few days left to get a revocation and refund, and start from scratch the right way. Don't you just love it when end-users jump the gun, and pay good money to a third party for things before you have the specs to give them? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection.close() has already been called during login
--- On Mon, 1/23/12, Christopher Schultz wrote: > From: Christopher Schultz > Subject: Re: Connection.close() has already been called during login > To: "Tomcat Users List" > Date: Monday, January 23, 2012, 2:42 PM > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > To whom it may concern, > > On 1/23/12 4:20 PM, removeps-c...@yahoo.com > wrote: > > My code does not talk to another cluster as I have a > single Tomcat > > only, but just wondering how one would scale. > > Me too. > > > Maybe the strategy to handle clusters is to write > information, such > > as the list of the users to the number of times > they have logged > > in in the last hour, into a location shared by all > machines. > > That sounds fairly straightforward. > > > In my code below the code is stored in failedAttempts > which is a > > Map where > FailedAttempt > > represents the number of times the user has logged in > in the last > > hour or whatever. It is in-memory, which is fine for > one Tomcat. > > Right. This is how Tomcat does things in its own > LockOutRealm. Take a > look at the code. It works with all realm types (see the > code for the > different authenticate() methods it implements). > > > But we could move this Map into a file that is on a > mounted drive > > available from all Tomcat machines, or we could store > it in the > > database. Either way we have to synchronize writes to > the file or > > database, and I think database does this > automatically, and maybe > > FileLock will do the job for the files. But anyway, it > sounds > > complicated. > > memcached. Cassandra. Whatever. > > > As for my my authenticate it was as follows, although > I don't see > > this should cause the failure in the subject of this > email -- > > "Connection.close() has already been called during > login": > > Yup, it certainly doesn't look like your code does anything > with the > superclass's Connection. > > > public Principal authenticate(String username, String > credentials) > > { threadUserLockedOut.remove(); > > Why in the world are you using a ThreadLocal in here? The use of the ThreadLocal is unrelated to the connection timing out. It's just a variable to indicate that in this thread the user is locked out. It is used later by my RootFormAuthenticator which extends FormAuthenticator to print out a message like "Your account has been locked out due to N failed attempts". FYI @Override protected void forwardToErrorPage(Request request, HttpServletResponse response, LoginConfig loginConfig) throws IOException { ... if (realm.isThreadUserLockedOut()) { message.append("Your account has been locked out due ... } else { message.append("Sorry, the username or password you supplied is invalid. Please try again."); } realm.clearThreadUserLockedOut(); request.setAttribute("loginErrorMessage", message); super.forwardToErrorPage(request, response, loginConfig); } The actual error page, which is a jsp page, has on it the following HTML > It makes me wonder what other odd things you are doing in > your Realm > (or anywhere else for that matter). > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8d4moACgkQ9CaO5/Lv0PDL2QCeOM9Q4e1FTa/oQv3IuUtBqzQJ > 5G8AoJo9XrkNoz29zLAcNBeDir7QdYM9 > =Elm7 > -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: Critical Problem Tomcat 7
On 24/01/12 08:50, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lau, On 1/18/12 6:52 PM, Lau Eng Huat wrote: I have a strange problem. I have deleted a servlet from the project in netbeans but the uncompile source code still says the file exist. I'll bite. What does "uncomple source code" mean. Did you delete the .class file or the .java file or both? I have deleted the WEB-INF\classes and did a clean and build. Still the problems exists. Does anybody knows how to solved this problem ??? It's not really clear what the problem is. If you think something is really out-of-sync, you should: 1. Stop Tomcat 2. Completely remove your WAR file or exploded WAR Directory 3. Completely remove your CATALINA_BASE/work directory and its contents 4. Re-build your webapp cleanly and re-deploy it 5. Start Tomcat If those very sensible five steps don't help, then... 6. It might be worth clearing the contents of the ~/.netbeans/x.x/cache/ directory, too. (You won't find the file in an obvious package hierarchy of directories - it is probably just lumped into one of the all-*.dat files). If you wipe out everything in cache, then stop netbeans, it will take a while to start while it repopulates the cache by compiling all your files again. I don't know whether this will resolve your problem, but it wouldn't be the first time confusion was caused by something "supposedly deleted" under netbeans still hanging around. Regards, Brian Jan 19, 2012 7:46:37 AM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet AdminCardServletLogin as unavailable Jan 19, 2012 7:46:37 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Allocate exception for servlet ServletABC java.lang.RuntimeException: Uncompilable source code - AllReadyDeletedServlet If, after the above steps, you are still having problems, please post your entire catalina.out file back with your next post. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8d5CUACgkQ9CaO5/Lv0PAvLwCgw2ljN97KjA9XXiJLqdRukhag 1DIAnjTYUgxkFVcMF1QOJRM8XFEGjLjK =OTs2 -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: Tomcat 7 in Java 6 on V5R4 (. . . 3 . . . 2 . . . 1 . . . crash-on-takeoff)
Caldarale, Charles R wrote: One thing you didn't tell us was exactly how you start Tomcat. Have you tried starting Tomcat from a command prompt so you can see the display of the derived variables, such as CLASSPATH? We start it from a variation of the OS/400 CL program given in this blog entry by "BetterThanZero": http://as400samplecode.blogspot.com/2011/06/install-tomcat-on-iseries-as400-tomcat.html His CL program is: PGM ADDENVVAR ENVVAR(JAVA_HOME) + VALUE('/QIBM/ProdData/Java400/jdk15') MONMSG MSGID(CPF) SBMJOB CMD(QSH + CMD('/apache/apache-tomcat-6.0.32/bin/start+ up.sh')) JOB(CATALINA) JOBQ($jobqName) + CPYENVVAR(*YES) ALWMLTTHD(*YES) ours is adjusted to where we put Tomcat in the file system. And up until a few minutes ago (hours after I first looked at your post), how to launch from a command line had not occurred to me (the answer, of course, would be to type the value of the CMD parameter on the "adjusted" version of the SBM job above (sometimes, even after almost eighteen years of working with the AS/400 platform, I surprise myself with how dense I can be!). At any rate, qsh CMD('/WINTOUCH/TOMCAT/BIN/STARTUP.SH') produces: /WINTOUCH/TOMCAT/BIN/catalina.sh: 001-0019 Error found searching for command tty. No such path or directory. Using CATALINA_BASE: /wintouch/tomcat Using CATALINA_HOME: /wintouch/tomcat Using CATALINA_TMPDIR: /wintouch/tomcat/temp Using JRE_HOME:/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre Using CLASSPATH: /wintouch/tomcat/bin/bootstrap.jar:/wintouch/tomcat/bi n/tomcat-juli.jar at which point it sits there for under 2 seconds before terminating, leaving this in catalina.out: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader.findClass(URLClassLoader.java:432) at java.lang.ClassLoader.loadClass(ClassLoader.java:642) at java.lang.ClassLoader.loadClass(ClassLoader.java:608) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:236) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) By contrast, if I enter the same command on a command line on our V6 box, I got the same, except for the initial "no such path or directory" exception, and then it sat there until I signed on from another terminal session and (after first verifying that the port had opened) terminating Tomcat. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Unable to access images stored in webapps//WEB-INF/images ?
Dear Users Why am I able to access images stored here: http://localhost:8080/imageUploader/1234.jpg but not here: http://localhost:8080/imageUploader/WEB-INF/images/1234.jpg File permissions are the same Any ideas? Thanks Alastair - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unable to access images stored in webapps//WEB-INF/images ?
On Tue, Jan 24, 2012 at 12:21 PM, Alastair Baldwin < alastairgbald...@yahoo.co.uk> wrote: > Dear Users > > Why am I able to access images stored here: > > http://localhost:8080/imageUploader/1234.jpg > > > but not here: > > http://localhost:8080/imageUploader/WEB-INF/images/1234.jpg > > > File permissions are the same > > Any ideas? > > Thanks > > Alastair > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > catalina.policy file? Although I'm not clear why on earth would you like to store images inside the application WEB-INF directory?
Re: Unable to access images stored in webapps//WEB-INF/images ?
Tomcat doesn't let you access anything in the META-INF or WEB-INF folders. These folders have config for your system, and may contain passwords (such as META-INF/context.xml which has passwords for the datasources). Besides, people can get into WEB-INF/lib and WEB-INF/classes and web.xml and see your implementation details. --- On Mon, 1/23/12, Alastair Baldwin wrote: > From: Alastair Baldwin > Subject: Unable to access images stored in webapps//WEB-INF/images ? > To: "users@tomcat.apache.org" > Date: Monday, January 23, 2012, 5:21 PM > Dear Users > > Why am I able to access images stored here: > > http://localhost:8080/imageUploader/1234.jpg > > > but not here: > > http://localhost:8080/imageUploader/WEB-INF/images/1234.jpg > > > File permissions are the same > > Any ideas? > > Thanks > > Alastair > > - > 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: Unable to access images stored in webapps//WEB-INF/images ?
> From: removeps-c...@yahoo.com [mailto:removeps-c...@yahoo.com] > Subject: Re: Unable to access images stored in webapps//WEB-INF/images > ? > Tomcat doesn't let you access anything in the META-INF or WEB-INF folders. It's not just Tomcat - the servlet spec forbids direct client access to anything in WEB-INF. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restarting tomcat 7.0.23 on MAC OS X 10.6
Did a thread dump.. I have some locked threads and it just keeps going, any smoking gun here? Oliver-Billings-MacBook-Pro:bin ob$ sudo jstack -l 18866 2012-01-24 08:26:03 Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.4-b02-402 mixed mode): "http-bio-80-exec-11" daemon prio=5 tid=10d0e2000 nid=0x116732000 waiting on condition [116731000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <7f49d0798> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:680) Locked ownable synchronizers: - None "Attach Listener" daemon prio=9 tid=101d5e800 nid=0x111fd9000 waiting on condition [] java.lang.Thread.State: RUNNABLE Locked ownable synchronizers: - None "GameSessionDB.DBUpdateEventJob" daemon prio=5 tid=10d4df800 nid=0x1164ee000 waiting on condition [1164ed000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.watagame.gosupermodel.gamesession.GameSessionDB$DBUpdateEventJob.run(GameSessionDB.java:513) at java.lang.Thread.run(Thread.java:680) Locked ownable synchronizers: - None "GameSessionDB.DBUpdateEventJob" daemon prio=5 tid=103e06800 nid=0x129203000 waiting on condition [129202000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.watagame.gosupermodel.gamesession.GameSessionDB$DBUpdateEventJob.run(GameSessionDB.java:513) at java.lang.Thread.run(Thread.java:680) Locked ownable synchronizers: - None "GameSessionDB.DBUpdateEventJob" daemon prio=5 tid=103a7d800 nid=0x111a04000 waiting on condition [111a03000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.watagame.gosupermodel.gamesession.GameSessionDB$DBUpdateEventJob.run(GameSessionDB.java:513) at java.lang.Thread.run(Thread.java:680) Locked ownable synchronizers: - None "http-bio-80-exec-10" daemon prio=5 tid=101b79800 nid=0x12a9aa000 waiting on condition [12a9a9000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:126) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298) - locked <7f42a96f0> (a org.apache.tomcat.util.net.SocketWrapper) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Locked ownable synchronizers: - <7f48c81a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) "http-bio-80-exec-9" daemon prio=5 tid=103fc5800 nid=0x12a66c000 waiting on condition [12a66b000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <7f49d0798> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
Re: parallel webapp initialization
On 23 Jan 2012, at 21:12, David Rees wrote: > On Tue, Oct 11, 2011 at 6:42 AM, Mark Thomas wrote: >> I have added a patch based on the previous patches that adds: >> - threaded start/stop for Contexts >> - threaded start/stop for Hosts >> - threaded deployment >> >> Control over the number of threads is via server.xml and/or JMX. This >> can be changed dynamically. >> >> Review, feedback, testing etc. welcome. >> >> With 4 threads rather than the current 1 (on a 8-core machine), I saw a >> 20-25% improvement in start time with a large number of Contexts that >> all start quickly. I'd expect to see better results in situations where >> 1 few Contexts start slowly but most are quick. > > Resurrecting an old thread, but I've started using this in Tomcat > 7.0.25 with good results - have a Tomcat instance used for testing > with a couple dozen contexts that take a while to load each, but with > startStopThreads bumped up it reduces startup time from 60 seconds to > 20 seconds using all available CPU cores. Very helpful! That's great - and thanks for letting us know. If you have time, I think it would be interesting to know your application sizes, individual startup time and how many startStopThreads you are using. p > > Thanks! > > -Dave > > - > 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