Re: java.sql.SQLException: No more data to read from socket
Am Samstag, den 21.07.2012, 08:44 +0800 schrieb vijay mathew: For the last 2 failures, this issue appeared on Monday and DB gets restarted every Saturday. So I assume that this issue has to do something with the DB restart for the last 2 failures. However 1 months back, the same issue appeared on a Wednesday. So I was not able find a real pattern for this issue when I compare the last 3 failures. You are using a pool of connections. The pool maintains at least three different types of connections: * alive connections, which are borrowed to a client * alive connections, which are idling in the pool * closed connections, which wait to be opened by the pool When you restart the database, all alive connections will (probably) be broken. If you ask the pool for a new connection, it can give you a previously closed one and open it, or a previously alive (and probably broken) one. So you might be lucky by getting a newly opened one, or have bad luck and get a broken connection. The pool should prefer to give one of the alive connections to you, though. To mitigate the problem of handing out broken connections the pool often has functionality to check a connection, before it hands it to the client. When using the tomcat database connection pool, that feature can be configured by setting validationQuery to a valid SQL-query (e.g select 1 from dual for oracle) and testOnBorrow to true. On the other hand, your code could store the connection somewhere and use it after a long period of time again. If the database was restarted in the meantime, you would get that error, but the validation query in the pool would not be able to help you. Regards Felix --- On Fri, 20/7/12, Christopher Schultz ch...@christopherschultz.net wrote: From: Christopher Schultz ch...@christopherschultz.net Subject: Re: java.sql.SQLException: No more data to read from socket To: Tomcat Users List users@tomcat.apache.org Date: Friday, 20 July, 2012, 10:21 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vijay, On 7/19/12 8:25 PM, vijay mathew wrote: java.sql.SQLException: No more data to read from socket at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:74) at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:110) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:171) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:227) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:439) at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1042) at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:999) at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:584) at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:183) at oracle.jdbc.driver.T4CStatement.executeForDescribe(T4CStatement.java:774) at oracle.jdbc.driver.T4CStatement.executeMaybeDescribe(T4CStatement.java:849) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1186) at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:1377) at oracle.jdbc.driver.OracleStatementWrapper.executeQuery(OracleStatementWrapper.java:386) at com.merck.mrl.pcisrr.mrlsos.loginservlet.service(loginservlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) So, when this happens, it always happens alongside an Oracle restart, but an Oracle restart does not always mean you'll get one of these errors? - - -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/ iEUEARECAAYFAlAJixAACgkQ9CaO5/Lv0PDr8wCY2P8stZkV5AmvW28eYVf2wAYQ SACeJBVjBTrLzWTTtkH1Hcnsh5IPKLI= =pXsE - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAJjJ8ACgkQ9CaO5/Lv0PBKQgCcCQPPTZaSCmug5EBYrXhONKXv PskAn2hQ4zG+gQGK+9t7IyRqWO/0z2AM =ckQ+ -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional
Re: Location of Tomcat 7 jvm defualt settings...
On Fri, Jul 20, 2012 at 6:31 PM, Tony Anecito adanec...@yahoo.com wrote: Thanks for the quick reply Mark. Yes I saw your comments in one of your presentations about profilier and I am a fan of visualvm and have profiled Tomcat in the past but when down to 1-2msec not sure how much the profilier can pick up. I did notice that as the hotspot engine warms up the response times start to see improvement. I did adjust the -Xss256k from the default of 1M and I am looking forward to when I get home to see the results since the response times quickly went to 3msec after that was set and hope to see 1msec or below after running for 1 day if that change really helps. I did start out profiling the SQL and that helped and switching to the jtds jdbc driver which seem to help even more and of course eliminating the interprocess communication (Tomcat - JBoss). I made sure my data types in SQL server were unicode so the jdbc drive did not do extra conversion work to unicode. I am slowly moving to the front (JAX-WS to JAX-RS) and then a deep dive into OS tuning. After that I will stop tuning for another 6 months I guess. Tony, With all due respect, you sound like you are fiddling with settings to learn rather than tuning. What I understand by tuning a webapp is that you 1. Create a automated test script to simulate some load 2. You increase the load until the bring the webapp to its knees - either 80% CPU or responses taking 1/2 sec to return 3. Critical step - you tell your bosses the maximum level that the app can currently support, e.g. X concurrent users performing A and B and C routes through the app. 4. If they say that's all they need, then stop 5. Otherwise use a profiler to establish where the bottle neck is 6. Fix it 7. Repeat from step 2 Using this technique you make sure that you don't waste time fixing issues that aren't really issues. As a programmer, its kind of hurts to admit it, but programmers are wrong when thy guess where the performance issues are. Always. This isn't my idea - read the performance tuning books. You'll just make code more complicated, and less maintainable. IMO there is nothing wrong with fiddling with settings to see what they do. However unless you have a repeatable (read automated) test script that allows you to test after each individual change, you're just whistling in the wind. Now it is possible that I have all this wrong. Perhaps you have an automated script, and you are doing all the above. It doesn't sound from your description that this is the case, but if it is then I apologise HTH Chris
Re: Location of Tomcat 7 jvm defualt settings...
On 7/21/2012 11:09 AM, chris derham wrote: ... 1. Create a automated test script to simulate some load 2. You increase the load until the bring the webapp to its knees - either80% CPU or responses taking1/2 sec to return 3. Critical step - you tell your bosses the maximum level that the app can currently support, e.g. X concurrent users performing A and B and C routes through the app. 4. If they say that's all they need, then stop 5. Otherwise use a profiler to establish where the bottle neck is 6. Fix it 7. Repeat from step 2 Using this technique you make sure that you don't waste time fixing issues that aren't really issues. As a programmer, its kind of hurts to admit it, but programmers are wrong when thy guess where the performance issues are. Always. This isn't my idea - read the performance tuning books. You'll just make code more complicated, and less maintainable. I disagree here. Once in a great while (maybe 10% of the time), I think I know where my bottlenecks are going to be, and testing proves me right. Of course the other 90% of the time... D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Location of Tomcat 7 jvm defualt settings...
Lots of time I apply best practices that I learn over time or are recommended by experts (Like Mark Thomas). You do that first as early in the development life cycle as possible. Funny I guess how these best practices come from developers, vendors (like Sun and now Oracle) and DBA's ect. If you can not get your performance to be the best with light load or expected load (actual users) then the tests you menton are a waste of time and too late in the solution life cycle. Some of us do not have million dollar test systems like HP Performance Center (which I use since I lead a performance Testing team) or open source tools that support JAX-WS. So being proactive where you can rather than later is my motto. My goal was simple and achieved and usage in production was what I mentioned (1-2msec) and a combination of using leading edge techniques combined with the old fashioned way of doing things. Best Regards, Tony Anecito JavaOne 2010 Dukes Award winner for Innovation JavaOne 2010 Future of Java Winner Currently #1 App Store Download for 3D Mapping and #2 for video app --- On Sat, 7/21/12, David kerber dcker...@verizon.net wrote: From: David kerber dcker...@verizon.net Subject: Re: Location of Tomcat 7 jvm defualt settings... To: Tomcat Users List users@tomcat.apache.org Date: Saturday, July 21, 2012, 10:11 AM On 7/21/2012 11:09 AM, chris derham wrote: ... 1. Create a automated test script to simulate some load 2. You increase the load until the bring the webapp to its knees - either80% CPU or responses taking1/2 sec to return 3. Critical step - you tell your bosses the maximum level that the app can currently support, e.g. X concurrent users performing A and B and C routes through the app. 4. If they say that's all they need, then stop 5. Otherwise use a profiler to establish where the bottle neck is 6. Fix it 7. Repeat from step 2 Using this technique you make sure that you don't waste time fixing issues that aren't really issues. As a programmer, its kind of hurts to admit it, but programmers are wrong when thy guess where the performance issues are. Always. This isn't my idea - read the performance tuning books. You'll just make code more complicated, and less maintainable. I disagree here. Once in a great while (maybe 10% of the time), I think I know where my bottlenecks are going to be, and testing proves me right. Of course the other 90% of the time... D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: force embedded tomcat 7 to listen on ALL adresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/07/2012 19:31, Alexander Shutyaev wrote: Hi Christopher, I've found a solution to my problem although I believe it's more accurate to say I guessed it :) Maybe you'll be able to explain it to me. Here is the complete code: Tomcat tomcat = new Tomcat(); tomcat.setBaseDir(baseDir); tomcat.getConnector().setPort(8080); tomcat.getServer().setParentClassLoader(getClass().getClassLoader()); tomcat.getEngine(); // (1) tomcat.init(); tomcat.getHost().addAlias(127.0.0.1); // (2) tomcat.start(); tomcat.addWebapp(, path); (1) - this seems like it should be called from somewhere within Tomcat class during initialization, but somehow it isn't called, and without this line I get a NullPointerException (2) - this is my solution to the problem I've described before; without this line my app is only served on http://localhost:8080 but if I include this line my app is available on http://localhost:8080, http://127.0.0.1:8080 and all other assigned addresses like http://192.168.1.1:8080 etc The problems you are seeing are caused by the order you are calling the methods. 1. addWebapp() will create the necessary Engine and Host but these need to be in place before you call start(). 2. There is no need to call init(). Calling start() will call init() if it hasn't already been called. The following should work: Tomcat tomcat = new Tomcat(); tomcat.setBaseDir(baseDir); tomcat.getConnector().setPort(8080); tomcat.getServer().setParentClassLoader(getClass().getClassLoader()); tomcat.addWebapp(, path); tomcat.start(); Patches for improvements to the Tomcat Javadoc welcome. The Tomcat unit tests are a good source of examples of using the Tomcat class. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCzRTAAoJEBDAHFovYFnnpAcP/R0V7GzR7IRzBGQlbXugNkpJ 7GEiEi+8RZCm5gDv8w4Ap5v/dQg23O5QeLrZaWZf+3S91omql7wpavBqeYz9H0I6 VjgcXk7n/iNB8qsWCtZ/42SFH61VI8vqwjWgiuCzDtfWODIkyp+uZpDJPLvUHzQj BicYz6Ya1r2NUCzTRQzCB1ewcQgSJsBoiiHR6bxKZvZlW+LZKSCwnnPa0xIq9M90 101Hidr3FYzvQWSNmTvWeXQd7u7q5VnPnOvKz+GdoC1T5EcZberPTXyh5bmqEzTk USearjM26VoMPH8GxSmY4Sq3BZxn8cZZM9lBZ4onBaH4wM4ea8PfPuUrDn1AHqoO K/g5erElXM9PGkPE8rQdLws0pU8XxMIXdbjHcC/amYjGmG1tfOd0Kxrq+xCuEes3 Qzl6t9g+Q2pKV/tqJSmoaZszZfXLVX4cr9KHwoU5Hq83WJSvaKsDwMvWRT8+hZAt j9DGsIgurCtk3TxACgG73NdGLO1y96f1vOQNRb53zSOOjG6FhWeFxU1o+TijIJGL fuAF1zSqLC9Tro+iZNKfzQvK8hTymzTLORmtlWrQmvAwaIdFzlJM4Ut4qoRyGGiL g26HUjqord/nDG2xZ0CgMb/HjaZHxDnTLEh+iOGO5/pmdMciENw10GfF0snJyQht Kd5VRqQ7JpAbDgHxXClR =4xDL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: force embedded tomcat 7 to listen on ALL adresses
Hi Mark, The problem is that I have a dynamic app where webapps come and go, so I can't call addWebapp() before calling start(). The best I can do is a delayed start() - in my method that calls addWebapp() I can make a check - and if this is the first time - call start() after addWebapp(). Will this help? Can I safely call addWebapp() for 2nd and all other webapps after start() ? 2012/7/22 Mark Thomas ma...@apache.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/07/2012 19:31, Alexander Shutyaev wrote: Hi Christopher, I've found a solution to my problem although I believe it's more accurate to say I guessed it :) Maybe you'll be able to explain it to me. Here is the complete code: Tomcat tomcat = new Tomcat(); tomcat.setBaseDir(baseDir); tomcat.getConnector().setPort(8080); tomcat.getServer().setParentClassLoader(getClass().getClassLoader()); tomcat.getEngine(); // (1) tomcat.init(); tomcat.getHost().addAlias(127.0.0.1); // (2) tomcat.start(); tomcat.addWebapp(, path); (1) - this seems like it should be called from somewhere within Tomcat class during initialization, but somehow it isn't called, and without this line I get a NullPointerException (2) - this is my solution to the problem I've described before; without this line my app is only served on http://localhost:8080 but if I include this line my app is available on http://localhost:8080, http://127.0.0.1:8080 and all other assigned addresses like http://192.168.1.1:8080 etc The problems you are seeing are caused by the order you are calling the methods. 1. addWebapp() will create the necessary Engine and Host but these need to be in place before you call start(). 2. There is no need to call init(). Calling start() will call init() if it hasn't already been called. The following should work: Tomcat tomcat = new Tomcat(); tomcat.setBaseDir(baseDir); tomcat.getConnector().setPort(8080); tomcat.getServer().setParentClassLoader(getClass().getClassLoader()); tomcat.addWebapp(, path); tomcat.start(); Patches for improvements to the Tomcat Javadoc welcome. The Tomcat unit tests are a good source of examples of using the Tomcat class. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCzRTAAoJEBDAHFovYFnnpAcP/R0V7GzR7IRzBGQlbXugNkpJ 7GEiEi+8RZCm5gDv8w4Ap5v/dQg23O5QeLrZaWZf+3S91omql7wpavBqeYz9H0I6 VjgcXk7n/iNB8qsWCtZ/42SFH61VI8vqwjWgiuCzDtfWODIkyp+uZpDJPLvUHzQj BicYz6Ya1r2NUCzTRQzCB1ewcQgSJsBoiiHR6bxKZvZlW+LZKSCwnnPa0xIq9M90 101Hidr3FYzvQWSNmTvWeXQd7u7q5VnPnOvKz+GdoC1T5EcZberPTXyh5bmqEzTk USearjM26VoMPH8GxSmY4Sq3BZxn8cZZM9lBZ4onBaH4wM4ea8PfPuUrDn1AHqoO K/g5erElXM9PGkPE8rQdLws0pU8XxMIXdbjHcC/amYjGmG1tfOd0Kxrq+xCuEes3 Qzl6t9g+Q2pKV/tqJSmoaZszZfXLVX4cr9KHwoU5Hq83WJSvaKsDwMvWRT8+hZAt j9DGsIgurCtk3TxACgG73NdGLO1y96f1vOQNRb53zSOOjG6FhWeFxU1o+TijIJGL fuAF1zSqLC9Tro+iZNKfzQvK8hTymzTLORmtlWrQmvAwaIdFzlJM4Ut4qoRyGGiL g26HUjqord/nDG2xZ0CgMb/HjaZHxDnTLEh+iOGO5/pmdMciENw10GfF0snJyQht Kd5VRqQ7JpAbDgHxXClR =4xDL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
