I hope someone can shed a little light on this problem.
I am running a thin-client app on JBoss/Tomcat 4.0 connecting to SQL Srvr 8.0 using jtds-0.9.jar
It's been working great until just recently. I keep getting the following error:
14:48:14,091 WARN [WrappedConnection] Exception trying to close statement:
java.sql.SQLException: I/O Error: No client request to send
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:1749)
at net.sourceforge.jtds.jdbc.TdsCore.clearResponseQueue(TdsCore.java:623)
at net.sourceforge.jtds.jdbc.JtdsStatement.close(JtdsStatement.java:532)
at org.jboss.resource.adapter.jdbc.WrappedStatement.internalClose(WrappedStatement.java:782)
at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:106)
at com.gradient.db.DAOHelper.disconnect(DAOHelper.java:88)
at com.gradient.db.GenericDAO.runQuery2(GenericDAO.java:196)
at com.gradient.db.GenericDAO.runQuery(GenericDAO.java:116)
at com.gradient.db.GenericDAO.readRows(GenericDAO.java:840)
at com.camelbackra.valueObjects.ProspectsDataMgr.getCurrentRow(prospectsDataMgr.java:113)
at com.camelbackra.valueObjects.ProspectsDataMgr.getTableRows(prospectsDataMgr.java:145)
at com.camelbackra.web.batch.BatchProspects.getDataResults(BatchProspects.java:299)
at com.camelbackra.web.batch.BatchAction.doBatchView(BatchAction.java:1151)
at com.camelbackra.web.batch.BatchAction.execute(BatchAction.java:272)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at com.camelbackra.web.utilities.StripTextFilter.doFilter(StripTextFilter.java:266)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:186)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:186)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:19
8)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:44)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.ja
va:169)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11P
rotocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.io.IOException: No client request to send
at net.sourceforge.jtds.jdbc.SharedSocket.getNetPacket(SharedSocket.java:642)
at net.sourceforge.jtds.jdbc.ResponseStream.getPacket(ResponseStream.java:364)
at net.sourceforge.jtds.jdbc.ResponseStream.read(ResponseStream.java:109)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:1647)
... 53 more
14:48:14,091 INFO [STDOUT] 080320041735 - SQL Error - Invalid state, the Connection object is clos
ed. SELECT * FROM dbo.Prospect WHERE batchId='2398' AND batchRowId='484'
Prior to 0.9.1 we had a quite complicated (and thus very hard to test) statement concurrency implementation. As a conclusion, it had one very hard to spot bug, which manifested itself on high loads.
Things have been simplified a lot in the 0.9.1 release and we can now say (with a 99.9% certainty) that the bug is gone. Please upgrade to 0.9.1 or better 1.0, which will be out early next week. That should fix your problem.
As a side note, in case you did not intend this, you have at least two concurrent Statements executing at once on the same Connection. This is ok, as it's supported by jTDS (incorrectly in older versions) but it usually means that jTDS has to do a lot of caching (to memory and, after a certain threshold is reached, to disk). This can incur quite big performance penalties, so unless you really can't do without it, you should try to avoid this kind of situations as much as possible, especially if the queries you are executing return a lot of data.
Alin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right, I did not want concurrent statements in the first place. I noticed this late last night & found a bug in my code (that's what happens when you put curly-brackets in the wrong place.)
Again - thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hope someone can shed a little light on this problem.
I am running a thin-client app on JBoss/Tomcat 4.0 connecting to SQL Srvr 8.0 using jtds-0.9.jar
It's been working great until just recently. I keep getting the following error:
14:48:14,091 WARN [WrappedConnection] Exception trying to close statement:
java.sql.SQLException: I/O Error: No client request to send
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:1749)
at net.sourceforge.jtds.jdbc.TdsCore.clearResponseQueue(TdsCore.java:623)
at net.sourceforge.jtds.jdbc.JtdsStatement.close(JtdsStatement.java:532)
at org.jboss.resource.adapter.jdbc.WrappedStatement.internalClose(WrappedStatement.java:782)
ava:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
ava:186)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
ava:186)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
8)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:44)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.ja
va:169)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11P
rotocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.io.IOException: No client request to send
at net.sourceforge.jtds.jdbc.SharedSocket.getNetPacket(SharedSocket.java:642)
at net.sourceforge.jtds.jdbc.ResponseStream.getPacket(ResponseStream.java:364)
at net.sourceforge.jtds.jdbc.ResponseStream.read(ResponseStream.java:109)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:1647)
... 53 more
14:48:14,091 INFO [STDOUT] 080320041735 - SQL Error - Invalid state, the Connection object is clos
ed. SELECT * FROM dbo.Prospect WHERE batchId='2398' AND batchRowId='484'
My data source is set up thusly:
<local-tx-datasource>
<jndi-name>ggaMatchMSSQL</jndi-name>
<connection-url>jdbc:jtds:sqlserver://192.168.0.145:1433;DatabaseName=MatchMaster;sendStringParametersAsUnicode=false </connection-url>
<min-pool-size>0</min-pool-size>
<driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
<user-name>gobblygook</user-name>
<password>*</password>
<transaction-isolation>TRANSACTION_READ_UNCOMMITTED</transaction-isolation>
</local-tx-datasource>
Prior to 0.9.1 we had a quite complicated (and thus very hard to test) statement concurrency implementation. As a conclusion, it had one very hard to spot bug, which manifested itself on high loads.
Things have been simplified a lot in the 0.9.1 release and we can now say (with a 99.9% certainty) that the bug is gone. Please upgrade to 0.9.1 or better 1.0, which will be out early next week. That should fix your problem.
As a side note, in case you did not intend this, you have at least two concurrent Statements executing at once on the same Connection. This is ok, as it's supported by jTDS (incorrectly in older versions) but it usually means that jTDS has to do a lot of caching (to memory and, after a certain threshold is reached, to disk). This can incur quite big performance penalties, so unless you really can't do without it, you should try to avoid this kind of situations as much as possible, especially if the queries you are executing return a lot of data.
Alin.
Fantastic! Thank you for the quick response.
You're right, I did not want concurrent statements in the first place. I noticed this late last night & found a bug in my code (that's what happens when you put curly-brackets in the wrong place.)
Again - thank you!