[prev in list] [next in list] [prev in thread] [next in thread]
List: tomcat-user
Subject: Re: java.sql.SQLException: No more data to read from socket
From: Daniel Mikusa <dmikusa () vmware ! com>
Date: 2012-07-24 18:07:02
Message-ID: 9411749.437.1343153220840.JavaMail.daniel () cleveland
[Download RAW message or body]
----- Original Message -----
>
> Felix/Daniel,
> I have a question on your solution.
> 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.
>
> Suppose the client tries to get a connection from the pool, and if
> the connection is broken , the validation fails. If the validation
> fails, does the client gets a new connection from the pool.
When you define your connection pool in Tomcat (i.e. using a <Resource/> tag), if you \
have "testOnBorrow" set to true and a "validationQuery" specified then the connection \
pool will test connections before it distributes them to your application. If a test \
fails the connection that failed the test will be removed from the connection pool. \
The pool will then attempt to borrow another connection from the pool. This does not \
mean it will be a "new" connection though. It will just go back to the pool and try \
again.
From the DBCP documentation...
"The indication of whether objects will be validated before being borrowed from the \
pool. **If the object fails to validate, it will be dropped from the pool, and we \
will attempt to borrow another.** NOTE - for a true value to have any effect, the \
validationQuery parameter must be set to a non-null string."
https://commons.apache.org/dbcp/configuration.html
Dan
>
>
>
>
> --- On Sat, 21/7/12, Felix Schumacher
> <felix.schumacher@internetallee.de> wrote:
>
> > From: Felix Schumacher <felix.schumacher@internetallee.de>
> > Subject: Re: java.sql.SQLException: No more data to read from
> > socket
> > To: users@tomcat.apache.org
> > Date: Saturday, 21 July, 2012, 6:41 PM
> > 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
> > > <chris@christopherschultz.net>
> > wrote:
> > >
> > > > From: Christopher Schultz <chris@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-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > >
> > > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic