Обсуждение: java.net.SocketException: Connection reset by peer: socket write error
Hello! I'm only recently getting errors in an application that has been running fine before and I suspect it might be something to do with the JDBC-driver. I'm using pg74.215.jdbc3.jar with ColdFusion MX 6.1 on Windows 2000 Server; the error occurs always at the same position in the the script, which is really a batch of scripts that's doing a lot of statistical evaluation on survey-data. It's not a bug in the code though, as it has worked flawlessly before and hasn't been changed since and what's more, if I don't execute the whole batch of scripts in one go but split it in two runs, everything is working fine again. It seems that somewhere along the line, the Application Server just looses the connection to the database after about 2h17min total runtime of the batch. I'd be very glad if someone could give me a hint on where to dig to find the cause of this error. Here's the stack-trace: org.postgresql.util.PSQLException: Eingabe/Ausgabe-Fehler beim Flush zum Server: Exception: java.net.SocketException: Connection reset by peer: socket write error Stack Trace: java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124) at org.postgresql.core.PGStream.flush(PGStream.java:411) at org.postgresql.core.QueryExecutor.sendQueryV3(QueryExecutor.java:338) at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:121) at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:100) at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43) at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Stateme nt.java:517) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Stateme nt.java:50) at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Stateme nt.java:298) at coldfusion.server.j2ee.sql.JRunStatement.execute(JRunStatement.java:212) at coldfusion.sql.Executive.executeQuery(Executive.java:974) at coldfusion.sql.Executive.executeQuery(Executive.java:886) at coldfusion.sql.SqlImpl.execute(SqlImpl.java:229) at coldfusion.tagext.sql.QueryTag.setupCachedQuery(QueryTag.java:603) at coldfusion.tagext.sql.QueryTag.doEndTag(QueryTag.java:443) at cf07_05_gc_lieblingsspiel2einc1835711628.runPage(C:\webserver\mafo\gener ator_code\chartcode\07_05_gc_lieblingsspiel.inc:69) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357) at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1871) at cfindex22ecfm1542255035._factor24(C:\webserver\mafo\generator_code\index 2.cfm:174) at cfindex22ecfm1542255035._factor62(C:\webserver\mafo\generator_code\index 2.cfm:21) at cfindex22ecfm1542255035.runPage(C:\webserver\mafo\generator_code\index2. cfm:1) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:62) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:107) at coldfusion.filter.PathFilter.invoke(PathFilter.java:80) at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:24) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:47) at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:52) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersist enceFilter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:35) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:43) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.CfmServlet.service(CfmServlet.java:105) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:252 ) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527 ) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java: 192) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.j ava:348) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java :451) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.jav a:294) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66) End of Stack Trace at org.postgresql.core.PGStream.flush(PGStream.java:415) at org.postgresql.core.QueryExecutor.sendQueryV3(QueryExecutor.java:338) at org.postgresql.core.QueryExecutor.executeV3(QueryExecutor.java:121) at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:100) at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:43) at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Stateme nt.java:517) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Stateme nt.java:50) at org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Stateme nt.java:298) at coldfusion.server.j2ee.sql.JRunStatement.execute(JRunStatement.java:212) at coldfusion.sql.Executive.executeQuery(Executive.java:974) at coldfusion.sql.Executive.executeQuery(Executive.java:886) at coldfusion.sql.SqlImpl.execute(SqlImpl.java:229) at coldfusion.tagext.sql.QueryTag.setupCachedQuery(QueryTag.java:603) at coldfusion.tagext.sql.QueryTag.doEndTag(QueryTag.java:443) at cf07_05_gc_lieblingsspiel2einc1835711628.runPage(C:\webserver\mafo\gener ator_code\chartcode\07_05_gc_lieblingsspiel.inc:69) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357) at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1871) at cfindex22ecfm1542255035._factor24(C:\webserver\mafo\generator_code\index 2.cfm:174) at cfindex22ecfm1542255035._factor62(C:\webserver\mafo\generator_code\index 2.cfm:21) at cfindex22ecfm1542255035.runPage(C:\webserver\mafo\generator_code\index2. cfm:1) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:62) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:107) at coldfusion.filter.PathFilter.invoke(PathFilter.java:80) at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:24) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:47) at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:52) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersist enceFilter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:35) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:43) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.CfmServlet.service(CfmServlet.java:105) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:252 ) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527 ) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java: 192) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.j ava:348) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java :451) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.jav a:294) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66) Kind regards Markus
Markus Wollny wrote: > It seems > that somewhere along the line, the Application Server just looses the > connection to the database after about 2h17min total runtime of the > batch. > java.net.SocketException: Connection reset by peer: socket write error > at java.net.SocketOutputStream.socketWrite0(Native Method) Check for firewalls between the appserver and the database server. The error is a TCP-level connection error that means that the peer (the database server) unexpectedly disappeared on us, and we didn't see an orderly shutdown of the connection. If it always happens after a certain connection length, or after the connection has been idle for a certain period, it's likely that there is a stateful firewall in the way that is dropping the connection after that period. Failing that, does the database side log anything about the disconnection? -O
Hello! Thank you very much for this hint - there is indeed a firewall between this in-house appserver and the DB - and that's beenbugging me personally for ages, since idle PGAdminII-connects would be closed without notice, too, which causes longtimeout-waits in PGAdminII and forces me to restart the connection. This might be the cause for this issue, too - andthe admin of our inhouse network seems to be unable to resolve this firewall-behaviour. I'll try and see if it changesanything, if I switch off of the connection-persitancy ("Maintain connections across client requests"). Thanks again for your help! Kind regards Markus > -----Ursprüngliche Nachricht----- > Von: Oliver Jowett [mailto:oliver@opencloud.com] > Gesendet: Donnerstag, 2. Dezember 2004 22:26 > An: Markus Wollny > Cc: pgsql-jdbc@postgresql.org > Betreff: Re: [JDBC] java.net.SocketException: Connection > reset by peer: socket write error > > Markus Wollny wrote: > > It seems > > that somewhere along the line, the Application Server just > looses the > > connection to the database after about 2h17min total runtime of the > > batch. > > > java.net.SocketException: Connection reset by peer: socket > write error > > at java.net.SocketOutputStream.socketWrite0(Native Method) > > Check for firewalls between the appserver and the database > server. The error is a TCP-level connection error that means > that the peer (the database server) unexpectedly disappeared > on us, and we didn't see an orderly shutdown of the > connection. If it always happens after a certain connection > length, or after the connection has been idle for a certain > period, it's likely that there is a stateful firewall in the > way that is dropping the connection after that period. > > Failing that, does the database side log anything about the > disconnection? > > -O >