Bug 34170 - Connection reset by peer exception while performing basic authentication (db connection pool not being used)
Connection reset by peer exception while performing basic authentication (db ...
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Catalina
5.5.7
Macintosh other
: P1 critical (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-03-25 00:56 UTC by sowmya v
Modified: 2005-03-31 07:42 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sowmya v 2005-03-25 00:56:58 UTC
Hi,
Problem:
While trying to login to our application using basic authentication, there is an
sql exception being thrown. It starts working fine after tomcat is restarted.
This happens periodically. I am not sure about how often users logged in between
 periods of failure. It is possible that there was nobody using it for may be 15
days or so. It is critical that we fix this problem asap as the users are
unhappy about failures this often. 
What's puzzling is that while performing basic authentication, the connection
should be closed after the browser is exited. So how can there be a connection
reset problem!!!

Environment:

The basic authentication has been configured using JDBC Realm entry in
context.xml of the app. The backend database is Oracle 10G that is on a
different m/c from that where tomcat runs. 

Symptoms:
The server was restarted on Feb 25 and the log below shows socket exception on
Feb 27. When there was an attempt to login on Mar 15, there was an
authentication error. But the socket exception doesn't show up in the logs
anytime after Feb 27 although authentication failed once again on Mar 24. It is
not clear why there's only one socket exception but two authentication failures
between restarts of tomcat.

Feb 25, 2005 3:12:48 PM org.apache.catalina.startup.Catalina startINFO: Server
startup in 5250 msFeb 27, 2005 3:52:51 AM
org.apache.tomcat.util.net.PoolTcpEndpoint processSocketSEVERE: Socket error
caused by remote host /60.21.206.10java.net.SocketException: Connection reset by
peer        at java.net.PlainSocketImpl.socketSetOption(Native Method)        at
java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:240)        at
java.net.Socket.setTcpNoDelay(Socket.java:771)        at
org.apache.tomcat.util.net.PoolTcpEndpoint.setSocketOptions(PoolTcpEndpoint.java:502)
       at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:514)
       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:552)Mar 15, 2005 9:41:50 AM
org.apache.catalina.realm.JDBCRealm getPasswordSEVERE: Exception retrieving
password for "evm"java.sql.SQLException: Io exception: Connection reset       
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:124)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:161)
        at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:273)
        at
oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows(T4CPreparedStatement.java:800)
        at
oracle.jdbc.driver.OracleStatement.execute_maybe_describe(OracleStatement.java:912)
        at
oracle.jdbc.driver.T4CPreparedStatement.execute_maybe_describe(T4CPreparedStatement.java:693)
        at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:983)
        at
oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:2884)
        at
oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:2925)
        at org.apache.catalina.realm.JDBCRealm.getPassword(JDBCRealm.java:526)
        at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:399)
        at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:347)
at org.apache.catalina.realm.JDBCRealm.authenticate(JDBCRealm.java:347)       
at
org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:181)
       at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446)
       at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)  
     at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)  
     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:825)     
     at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:738)
       at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
        at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
Comment 1 Remy Maucherat 2005-03-25 01:08:52 UTC
This has already been fixed in CVS.

However, I recommend using the data source realm instead, which is more robust
and scalable (and setup is about the same).
Comment 2 sowmya v 2005-03-31 16:42:30 UTC
Could you please  clarify th:
1. What is the exact nature of the bug that has been fixed? Does it depend on the Oracle version or the 
OS?  Would moving the database to the same m/c where tomcat runs resolve the problem temporarily? 
2. When is the next stable version being released with this bug fixed?

(In reply to comment #1)
> This has already been fixed in CVS.
> 
> However, I recommend using the data source realm instead, which is more robust
> and scalable (and setup is about the same).