Re: Servlet Memory Leak
I have a fairly small memory leak in a servlet (Tomcat 6.0) running on a Windows 2003 server. I have been looking into memory profiling to help me find the leak but nothing seems to be or do what I need. Simply put I want a list of all of the objects/primitives (and if possible their values) that are in memory. It would be really nice if I didn't have to bring Tomcat down at all to do this analysis as the servlet is running in a production environment. Does anyone know of a decent free tool that does such a thing? If not, what would be a good route to take to find this leak? Thanks a ton. I just finished debugging a major memory leak in my servlet application. Try running the tool jmap that comes with java. It works great with Tomcat - just find the PID of the Tomcat (java) instance and run it on that. For example, fire up Windows Task Manager, go to Applications and find Tomcat. Right-click and choose go to process. This will move you to the Process pane highlighting the Tomcat (java) process ID. Now open a command (console) window and (assuming you have Java paths set correctly), type: jmap -histo PID output.txt (or output.txt - although I used sequentially numbered output files) This will capture the stack info into a file for analysis. The PID is the process ID you noted from the Task Manager. If you run this just after you start Tomcat, then a few times after doing the things that you suspect trigger the memory leak, you should see objects in the map that you can identify as not getting released and thus zero in on the leak. Cheers, -Richard - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to monitor memory use offline
Richard, Richard S. Huntrods wrote: | Everything is local except the pooled connections, so I would say this | is the problem. This code was originally written before tomcat had good | connection pools, and so I had to write my own. The pool is basically a | vector of connections. I wouldn't want to blame your connection pool just yet; I'm just saying that it is a possibility. The open-source connection pools have a /lot/ of users and a /lot/ of eyes looking at them, and tend to be very stable. Your in-house connection pool may not have been as thoroughly tested. My in-house connection pool was based on code examples from around 2001 - when I first implemented the system. My database classes were from the same time, hence the almost correct nature of the code (close statements, finally clause). It all worked without incident until this July, when I was required to upgrade an aging server and also upgraded all of the packages. We had been using the original mmjb.jar version (predating when MySQL took over the connector/J project). It took a while to trace the memory leaks to the connector, and then it was quick work to find the version split where the leak started. (see prior posts). In that time I had been reading as much as possible about Tomcat memory use, leaks, and finally stuff about the connector. | At a more fundamental level, I still don't think the new connector is | working correctly (and I've read many of the forum discussions about | this...). Has anyone mentioned the behavior you are observing? Were those posts anything but idle speculation, or has anyone come to an actual conclusion about the cause of the errors? The majority of the posts I'm referring to occurred in 2004. Many people were noticing memory leaks with the connectors, and wanting to call them Bugs. The database folks and connector authors fiercly defended their work and stated the problem was always due to missing close() statements. The discussion then turned toward misinterpretation of the JDBC specification - where the people complaining about the leak insisted the spec. required the connector to release all memory objects as soon as the statement went out of scope and the connector people saying No - you must call close(). SO I put the appropriate close() for statement in my code - but to no effect. With the exception of my connection, my code now matches what is correct. | If I close the resultset AND the statement, then the connector | should release all the objects created by those two. The connection is, | after all, just a pipe between the database and the java code. The | connector should not (IMO) be hanging on to statement or resultset | objects just because the connection is still in existance. I completely agree. Two things that I can think of that might be causing problems with the Connector itself: 1. ResultSetMetadata -- use of the metadata methods can cause additional queries to be executed, which means more ResultSet objects, Fields, etc. I didn't see any use of this in your sample code, so I suspect this is not the issue. Actually, it is. I use a RSMD object in all my queries. I don't close it. - MAYBE THAT's THE PROBLEM. I will test and report... 2. Client-side PreparedStatement caching. Have you enabled any of the caching options provided by the driver? I'm guessing not, since you were using a 3.x driver before, which IIRC does not support such caching. Nope. No caching at all. | Still - this is most clearly NOT my problem as I can verify my code is | working normally (i.e. no exceptions happening) and thus properly | closing both the resultset and the statement. Agreed. | For fun I put try-catch blocks with additional resultset and statemtent | calls to close in the finally block and it made no difference to the | memory leak. Right. I would not have predicted that you would change anything by doing this -- it's just a good practice to get into in the event that exceptions /do/ start cropping up. Agreed. | Yea - the code was developed a long while ago. There's also a single | version that can run under Tomcat or as offline processes and I don't | want to have to write two different database mechanisms to support the | application outside of Tomcat. Tomcat uses JNDI DataSources to provide connection pooling. This is very easy to do outside of Tomcat if you are interested. Another option would be gut your existing CP implementation and replace it with pass-through calls to a library like commons-dbcp. This is exactly what I did with a project that I inherited a few years ago and many, many JDBC-related problems went away (more to do with connection leakage than memory leakage). Sounds like a plan - if ever I have time to do this. ;-) My last suggestion would be to use a real memory profiler. These tools can typically tell you exactly where in your code a particular object was instantiated. After you run your program for a while, inspect the heap
Re: Would like to monitor memory use offline
Chris,
| If I close the resultset AND the statement, then the connector
| should release all the objects created by those two. The connection is,
| after all, just a pipe between the database and the java code. The
| connector should not (IMO) be hanging on to statement or resultset
| objects just because the connection is still in existance.
I completely agree. Two things that I can think of that might be causing
problems with the Connector itself:
1. ResultSetMetadata -- use of the metadata methods can cause additional
queries to be executed, which means more ResultSet objects, Fields, etc.
I didn't see any use of this in your sample code, so I suspect this is
not the issue.
OK. I tried closing RSMD's. You can't close them so I just made them
null. It had no effect, but I'm not surprised since they come from the
ResultSet and should (in theory) be destroyed when the ResultSet is
closed (IMO).
HOWEVER - In messing with the code again ...
I FIXED THE PROBLEM!
Yep - totally fixed (tested and verified).
What I decided to do was to move the close statements (and nulling RSMD)
into the FINALLY block - it seemed pointless to duplicate code. When you
must have the close() statements in finally, why put them in the main
code as well?
So I modified ALL my DBMS methods as follows (just showing the finally
block):
finally {
try {
if(resultSet != null) {
resultSet.close();
resultSet = null;
}
if(statement != null) {
statement.close();
statement = null;
}
}
catch (Exception e) {
}
}
In doing this, I found several methods I missed earlier - they were
update and delete methods that didn't use ResultSet so I had missed
adding the statement.close().
So once I was done, EVERY METHOD in the DBMS class had appropriate
closes on resultsets and statements (as appropriate) - all placed in the
finally block.
Testing proved this to completely fix the memory leak.
Thanks again VERY much for all the advice and assistance!!!
:-)
Cheers,
-Richard
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to monitor memory use offline
Richard,
Richard S. Huntrods wrote:
| Richard,
|
| Richard S. Huntrods wrote:
| |public static Vector listLookup(String table) {
| | //Connection connection = null; // connection is managed
by a
| | connection pool
|
| So, is 'connection' a local or not?
| It's part of my code (I use my own connection pool class) but not to
the
| DBMS code. Only if you can't get a connection from the pool
| (connection==null) do you create a local one for this method.
|
| If the connection from the pool is OK, you use it then release it back
| to the pool. If it's local (because you could not get one from the
pool)
| then you close it in the finally block.
I think you are misunderstanding me: I'm asking if you are using a
shared java.sql.Connection reference among all threads running your db
code. If you are, then you've got a big problem, which could explain
some of the memory leaks you are seeing. If you have a class-level
reference like this:
public class MyDBMSMethods
{
~ private Connection connection;
~ public List getMyRecords()
~ {
~ connection = getConnectionFromPool();
~ ...
~ }
}
... then you should expect lots of problems. From your posted code, it
looks like this is what you are doing.
All connection references should be strictly local to each method. Each
method should get its own connection from the connection pool, use it,
and return it to the pool (unless you accept the connection as a
parameter to the method, in which case, you should use it).
Everything is local except the pooled connections, so I would say this
is the problem. This code was originally written before tomcat had good
connection pools, and so I had to write my own. The pool is basically a
vector of connections.
At a more fundamental level, I still don't think the new connector is
working correctly (and I've read many of the forum discussions about
this...). If I close the resultset AND the statement, then the connector
should release all the objects created by those two. The connection is,
after all, just a pipe between the database and the java code. The
connector should not (IMO) be hanging on to statement or resultset
objects just because the connection is still in existance.
| You need to have statement.close() and resultSet.close() in here
(in the
| finally block), not up above. Also, most database connection pools
| require that you call connection.close() to return the connection
to the
| pool. Are you ever calling connection.close()?
|
| Um, sorry to disagree, but that is not really correct and also does not
| touch my problem.
Not closing your resources in a finally block it surely /not/ correct,
and you /can/ leak resources in this way. Which part of my statement is
not correct?
Yea - looked further and I have seen try/catch blocks in finally code.
Still - this is most clearly NOT my problem as I can verify my code is
working normally (i.e. no exceptions happening) and thus properly
closing both the resultset and the statement.
For fun I put try-catch blocks with additional resultset and statemtent
calls to close in the finally block and it made no difference to the
memory leak.
| I am already closing the resultSet and statement in the normal
| execution part of my code. At no time during the execution of this
code
| in these tests was an exception thrown in this method
It doesn't matter. If you do not close your resources in a finally
block, they are not guaranteed to be closed. It might not be your
current problem, but it could be your future problem.
I will not disagree with this. That's why the finally is there in the
first place.
| so *I was now
| correctly closing the statement and resultSet. YET IN SPITE OF THIS the
| versions of the connector after 3.1.10 FAIL to release the Field
objects.
|
| The other reason NOT to put close() in the fianlly block is that the
| close() methods can throw and exception.
That's why you wrap the call to close() in its own try/catch block.
| It is very bad programming
| practice to put exception throwing code' in a finally block. Sure, you
| could use another try-catch structure for the close() statements, but
| really - you should have already closed the stuff in the normal
| execution (as I did).
If you say so. My code doesn't leak DB resources, and it is written in
this way.
| I did state one thing in error - the finally block (of course) ALWAYS
| gets called, so you only want code in that block that must be done
after
| all else has happened, but you also don't really want to be repeating
| code that should go elsewhere (like the close()).
|
|
| Also, which connection pool do you use?
|
| My own.
Is there a compelling reason not to use one of the freely-available,
well-supported connection pools available? Tomcat even has one already
built into it.
Yea - the code was developed a long while ago. There's also a single
version that can run under Tomcat or as offline processes and I don't
want
Re: Would like to monitor memory use offline
Chris,
Richard,
Richard S. Huntrods wrote:
| In my code I was calling resultSet.close(), but not statement.close().
That'll do it.
Actually, fixing it did NOT help. See more below...
| The problem is, even though I verified (debug statements) that the call
| is being made, the memory is STILL not being released. If I run the
same
| large query 3 times in a row, my memory use triples. Even if I log off
| the session (my application) and invalidate the session, the memory is
| still locked up and cannot be freed by the JVM.
Can you post some (sanitized) code? Maybe you're still missing something.
My sanitized code looks exactly like the code you posted below. I put
all my actual database work inside a DBMS class so that I could change
it out anytime without messing the application, and it's worked well.
Each different type of database access has it's own method (lookup,
lookupList, insert, delete, update, etc...). Each method opens ONE
connection, ONE statement and gets ONE resultSet. When I'm done, I close
the resultSet and (now) the statement. I also have full exception
handlers plus the necessary finally clause.
I also know from running my application that no exceptions are occurring
during the memory leak (no output to the debug file).
Remember that you can't just close the statement when you're done with
your method... if you use multiple Statements and ResultSets, you have
to close them as you so. You also have to make sure that you have a
finally block that closes them in case of an exception condition.
I never use multiple statements and resultSets. That's just asking for
trouble, IMO. ;-)
I've posted it before, but I'll to it again because it bears repeating:
here is the proper way to write JDBC code:
Connection conn = null;
~PreparedStatement ps = null;
~ResultSet rs = null;
~try
~{
~conn = getConnection(); // however you get your connections
~ps = conn.prepareStatement(...); // your query
// set params, etc.
~rs = ps.executeQuery();
// do whatever you need to do with your ResultSet
~}
~finally
~{
if(null != rs) { rs.close(); } catch (SQLException sqle)
{ /* log this error! */ }
if(null != ps) { ps.close(); } catch (SQLException sqle)
{ /* log this error! */ }
if(null != conn) { conn.close(); } catch (SQLException sqle)
{ /* log this error! */ }
~}
Yep - my code looks pretty much just like this.
I wrote a method in a utility class that does everything in the finally
block -- it makes the code much easier to read IMO.
Agreed. Me too.
Note that if you need multiple Statements, you should either use them
serially, and close each statement before you move onto the next one
(and re-use the local variable), or you should define them all outside
of the try/finally block and make sure they are closed under all
conditions. If you don't do this, you'll leak memory.
If you are using transactions, remember that you must catch /every
exception that can possibly occur/ (yes, even Errors and
RuntimeExceptions) and make sure you do a rollback before you close
everything.
| So what am I missing? I was sure that adding the code to close my
| statements would fix the problem.
Is it possible that the code you're looking at is good, but some other
code has a similar leak but is yet to be fixed.
As I said, 3.0.17 works PERFECTLY (no memory leaks, memory use hovers
around 50 megs of stack. With 3.1.10 and newer, memory use immediately
starts to climb immediately. It quickly reaches (within 30 min) 500
megabtyes ( of a 1 gig stack) and after an hour it hits the stack limit
and tomcat crashes. This is even with the UseParallelOLDGC garbage
collector in use to compact the old stack (without it the system crashes
even sooner due to fragmenting).
| So - does anyone know what the major change was between 3.0.17 and
| 3.1.10 that would have such a dramatic effect?
http://dev.mysql.com/doc/refman/5.0/en/cj-news.html
It's possible that newer versions of the JDBC driver more properly
adhere to the JDBC specification which results in memory leakage
(because JDBC expects you to code in very rigid ways, including cleaning
up your own memory messes ;) .
That's what I am thinking as well - or a newer JDBC spec. Otherwise how
to explain a ONE DAY release date difference by a MAJOR version change
(3.0.17 on June 22/05 - 3.1.10 on June 23/05).
I use mysql-connector-5.0.8.jar and have not had a problem in a very
long time.
I am quite sure that something was changed in the spec that altered the
way the code should be written, and the old way (3.0.17) was probably
automatically cleaning up while the new way (3.1.10 and above) expects
the programmer to clean up.
PROBLEM IS, according to all docs I *am* doing the proper cleanup.
HERE IS MY neutered code:
public static Vector listLookup(String table
Re: Would like to monitor memory use offline
Well, thanks to Lamda probe and then to jmap, I have found my memory leak. Here are the gory details in case anyone is interested. It's not really a Tomcat issue, but rather the boundary between Tomcat and MySQL: I have a memory leak in my application, and jmap shows me that all my objects of type 'com.mysql.jdbc.Field' are not being released. In my code I was calling resultSet.close(), but not statement.close(). Doing my homework, I found the forum postings about this and so corrected my code to include statement.close() as well as resultSet.close() after my database operations. The problem is, even though I verified (debug statements) that the call is being made, the memory is STILL not being released. If I run the same large query 3 times in a row, my memory use triples. Even if I log off the session (my application) and invalidate the session, the memory is still locked up and cannot be freed by the JVM. My application is java servlets, using Java 1.6.0_06-b02, Tomcat 6.0.15 with mysql-connector-java-5.1.6-bin.jar and Mysql 5.0.51b. So what am I missing? I was sure that adding the code to close my statements would fix the problem. UPDATE: OK. In a way, I've fixed the problem. I checked my source code, and I'm now issuing the correct close() statements as required, so the memory leak is a puzzle. BUT - I went back through past versions of the jdbc connector because *** this application used to work without any problems ***. Here's what I found. (GOOD means no memory leaks at all - even under extended testing; BAD means memory leaks immediately). GOOD: mysql.jar (221 kb, 10/7/2003) mysql-connector-java-3.0.16-ga-bin.jar (231 kb, 11/16/2004) mysql-connector-java-3.0.17-ga-bin.jar (241 kb, 6/22/2005) BAD (memory leak): mysql-connector-java-3.1.10-bin.jar (409 kb, 6/23/2005) mysql-connector-java-3.1.14-bin.jar (449 kb, 10/18/2006) ... (other versions) mysql-connector-java-5.1.6-bin.jar (687 KB, 3/5/2008) So - does anyone know what the major change was between 3.0.17 and 3.1.10 that would have such a dramatic effect? Again, I realize this is not strictly a Tomcat problem (tomcat version is pretty much irrelevant to the problem), but many using Tomcat also use MySQL, so it's still of interest. Cheers, -Richard - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Would like to monitor memory use offline
To Ben Mark, Thanks for the replies. I've been trying various things based on your suggestions. I find my best tool at the moment is Lambda Probe - though it hasn't been updated in a while, it does show me all the things (for the most part) that I wanted to watch. There's definitely some kind of problem with the JVM not releasing the PS Old Gen memory. I can watch as this gets gradually used up until it hits the max value - then Tomcat crashes with the GC/Heap error message. If I stop and start Tomcat before this limit is reached, the memory use resets to 0 and the system does not crash. What is puzzling is that this identical system was working for weeks on end without a problem under the older versions of Java, Tomcat and Mysql I posted in my original post - and with 1/2 the stack. Only when I moved to the new servers (with all the new versions) did the GC crashes start. Now I'm trying different GC managers to see if one of them works better at freeing up memory - like maybe the compation parallel GC. We'll see. Again, thanks for the relies. Cheers, -Richard - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Would like to monitor memory use offline
I've been running Tomcat for many versions now, mostly without incident. However with the latest set of upgrades rather forced upon me all at once (instead of managed more properly), my application appears to have a severe memory leak. System Info: OS is Solaris 10-u5 (2008); java 1.6.0_06-b02; apache-tomcat-6.0.16; mysql 5.0.51a-solaris10-x86_64. I have fast servers and plenty of memory (8 gigs). I'm running 1 gig stack and getting at least 2 GC/stack exceptions per day (sometimes more). Yes - it's a user/use triggered leak but I can't trace it further yet. Of course what is odd is that there was NO memory leak using older versions of this stuff (Solaris 10 (2006), java 1.5.x, tomcat 5.5.12, mysql 5.0.16). I'm sure the memory leak was there, but it was well masked. On the older system I was running 512 meg stack and it never gave GC or stack errors. So, while I am actively trying to fix the memory leak, I still have to maintain these production servers at operatonal status (politics - don't ask). However, it's difficult as the memory leak is causing repeated GC and out of stack exceptions. What I've noticed recently is that when using the manager application, I can watch the memory utilization grow and more memory get allocated (via refreshing the page), right up until the stack is used up and the main application crashes. However, if I'm watching it grow, and then log on to the server and reset tomcat (stop and then start tomcat), the memory use is back at the start. Thanks to session persistence, no users are harmed during this exercise. So for the moment, while I try and debug the application, I can keep things running by having a cron job periodically reset tomcat for me. But this is really crude. Until I fix the memory leak, I'd like something a little bit more elegant. SO - my question - is there a relatively easy way to create something (say a servlet) to watch the stack *just like I can do manually using the manager application* but email me when the stack approaches the memory limits? Thanks, -Richard - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Would like to know what might be causing this exception in servlet
Thank you Chuck and Tim for the information. I did wonder if it was a normal exception, now I know that it's at least nothing to worry about. I have one more. This *IS* a real error, and is caused by something breaking between MySQL and my servlets. SQL Problem: Communication link failure: java.net.SocketException, underlying cause: Connection reset ** BEGIN NESTED EXCEPTION ** java.net.SocketException MESSAGE: Connection reset STACKTRACE: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1399) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1775) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1020) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1109) at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1070) at com.mysql.jdbc.Connection.execSQL(Connection.java:2027) at com.mysql.jdbc.Connection.execSQL(Connection.java:1984) at com.mysql.jdbc.Statement.executeUpdate(Statement.java:1248) at com.mysql.jdbc.Statement.executeUpdate(Statement.java:1194) at my.DBMS.keyUpdate(Unknown Source) at my.MyReport.doPost(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419) at org.apache.catalina.servlets.InvokerServlet.doPost(InvokerServlet.java:169) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) ** END NESTED EXCEPTION ** SQL State: 08S01 Vendor Error: 0 Only two classes here are mine, the rest are Tomcat and the JDBC driver. My code is simply trying to update a record in the database, when (it appears) the communication link to the database fails. When checked, MySQL is running just fine, and continues to run fine. The current workaround is to detect this condition, and simply stop and restart Tomcat (/etc/init.d/tomcat.server stop; /etc/init.d/tomcat.server start). Any ideas why the communication link to the database just dies? Again, Tomcat is still running, and the database is also still running just fine (other applications using the same database are still working when this happens). Thanks in advance, -Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MySQL Database / Tomcat Exceptions
From: Richard S. Huntrods [mailto:[EMAIL PROTECTED] Subject: RE: Would like to know what might be causing this exception in servlet I have one more. This *IS* a real error, and is caused by something breaking between MySQL and my servlets. (Should probably start a new thread for this, since it's a different issue.) It looks like the other end (MySQL) decided to drop the connection. Could be a timeout problem, or a network hiccup (e.g., somebody tripped over a cable). Is this reproducible? Can you get a network capture of the situation? - Chuck Thanks, Chuck. I am thinking along similar lines. The only problem is that aside from the Java exception, there are no error messages in any other Tomcat logs or MySQL logs. Here's another one from today: DBMS SQLException. Time:Mon Feb 06 14:46:06 MST 2006 SQLException caught: keyLookup(login : 50768) DBMS SQLException. Time:Mon Feb 06 14:46:06 MST 2006 SQL Problem: Communication link failure: java.io.IOException, underlying cause: Unexpected end of input stream ** BEGIN NESTED EXCEPTION ** java.io.IOException MESSAGE: Unexpected end of input stream STACKTRACE: java.io.IOException: Unexpected end of input stream at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1405) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1775) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1020) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1109) at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1070) at com.mysql.jdbc.Connection.execSQL(Connection.java:2027) at com.mysql.jdbc.Connection.execSQL(Connection.java:1984) at com.mysql.jdbc.Statement.executeQuery(Statement.java:1152) at my.DBMS.keyLookup(Unknown Source) at my.Person.lookup(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:133) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) ** END NESTED EXCEPTION ** SQL State: 08S01 Vendor Error: 0 Again, basically Tomcat seems to just lose the connection to MySQL. Any suggestions? -Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Would like to know what might be causing this exception in servlet
I am getting this exception from time to time (maybe once in a day every few days) with my application (Servlets). None of the code involved in the stack trace is my code, so I'm wondering if anyone knows what is the cause of this exception? Also, is there a workaround / fix? Thanks very much in advance, -R Feb 1, 2006 9:09:33 PM org.apache.tomcat.util.net.PoolTcpEndpoint processSocket SEVERE: Socket error caused by remote host /204.244.137.23 java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:284) at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:319) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:720) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1038) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:119) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:520) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
help in setup ssl in tomcat
hi all I would like to establish public key private key ssl setup in tomcat. I dont know how to proceed please help me regarding this. regards Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
