Derby
  1. Derby
  2. DERBY-2026

Setting a login timeout in client driver can lead to query timeout

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: 10.5.3.1, 10.6.2.1, 10.7.1.1
    • Component/s: JDBC, Network Client
    • Labels:
      None
    • Environment:
      Client driver on most platforms
    • Urgency:
      Normal
    • Issue & fix info:
      Patch Available, Repro attached
    • Bug behavior facts:
      Seen in production

      Description

      Setting the login timeout by using DriverManager.setLoginTimeout(int
      seconds) also affects the amount of time the client driver is waiting
      for a query to finish. For instance, setting the login timeout to 10
      seconds will result in any queries taking more than 10 seconds to fail
      with the following exception:

      Exception thrown: java.sql.SQLException: A communications error has been detected: Read timed out.
      java.sql.SQLException: A communications error has been detected: Read timed out.
      at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46)
      at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345)
      at org.apache.derby.client.am.Statement.executeQuery(Statement.java:414)
      at LoginTimeout.main(LoginTimeout.java:53)
      Caused by: org.apache.derby.client.am.DisconnectException: A communications error has been detected: Read timed out.
      at org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(NetAgent.java:408)
      at org.apache.derby.client.net.Reply.fill(Reply.java:176)
      at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java:215)
      at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317)
      at org.apache.derby.client.net.Reply.startSameIdChainParse(Reply.java:1147)
      at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(NetStatementReply.java:51)
      at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(StatementReply.java:40)
      at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(NetStatement.java:139)
      at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Statement.java:1341)
      at org.apache.derby.client.am.Statement.flowExecute(Statement.java:1977)
      at org.apache.derby.client.am.Statement.executeQueryX(Statement.java:420)
      at org.apache.derby.client.am.Statement.executeQuery(Statement.java:405)
      ... 1 more
      Caused by: java.net.SocketTimeoutException: Read timed out
      at java.net.SocketInputStream.socketRead0(Native Method)
      at java.net.SocketInputStream.read(SocketInputStream.java:129)
      at org.apache.derby.client.net.Reply.fill(Reply.java:174)
      ... 11 more

      1. LoginTimeoutWithDataSource.java
        2 kB
        Kathey Marsden
      2. LoginTimeout.java
        2 kB
        Olav Sandstaa
      3. DERBY2026_LoginTimeout_diff_patch1.txt
        0.5 kB
        Mamta A. Satoor
      4. derby-2026_diff.txt
        8 kB
        Kathey Marsden

        Issue Links

          Activity

          Hide
          Olav Sandstaa added a comment -

          This is a repro showing that setting the login timeout to 10 seconds makes the folloiwng query to fail with the exception shown in the JIRA report.

          To run the repro:

          1. start a Derby network server
          2. update the jdbcUrl in the java program with the correct server and port number
          3. Run the repro program. This program should produce the execption after about 10 seconds.

          To make the program succeed, remove the call to DriverManager.setLoginTimeout(). Note that the program then might
          take about 2 to 10 minutes to complete the query.

          This repro will fail to reproduce the bug if you have a machine that is much faster than than the one I am using or if you are running on an operating system that does not support setting a timeout on blocking socket calls.

          Show
          Olav Sandstaa added a comment - This is a repro showing that setting the login timeout to 10 seconds makes the folloiwng query to fail with the exception shown in the JIRA report. To run the repro: 1. start a Derby network server 2. update the jdbcUrl in the java program with the correct server and port number 3. Run the repro program. This program should produce the execption after about 10 seconds. To make the program succeed, remove the call to DriverManager.setLoginTimeout(). Note that the program then might take about 2 to 10 minutes to complete the query. This repro will fail to reproduce the bug if you have a machine that is much faster than than the one I am using or if you are running on an operating system that does not support setting a timeout on blocking socket calls.
          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2.
          Hide
          Dag H. Wanvik added a comment -
          Show
          Dag H. Wanvik added a comment - Setting "seen in production" flag, cf. http://www.nabble.com/Re:-%27Read-timed-out%27-error-on-update-query-p25352256.html
          Hide
          Mamta A. Satoor added a comment - - edited

          The issue is setting a login timeout is also causing the queries to time out within that time. I did some debugging of the code and following is what I saw.

          It appears that if the user has asked for login timeout, then during the connection setup time , we call setSoTimeout on the the socket which is used for communication.

          The api defination for setSoTimeout api on Socket says follows
          public void setSoTimeout(int timeout) throws SocketException
          Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a
          non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this
          amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the
          Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect.
          The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.
          Parameters:
          timeout - the specified timeout, in milliseconds.
          Throws:
          SocketException - if there is an error in the underlying protocol, such as a TCP error.

          So, it looks like that this setSoTimeout setting is applicable not just for the login time but also for every interaction after that
          which in our test case includes the query execution.

          The code path for setSoTimeout call on socket through our connection set up is as follows
          Thread [main] (Suspended)
          NetAgent.<init>(NetConnection, LogWriter, int, String, int, int) line: 142
          NetConnection.newAgent_(LogWriter, int, String, int, int) line: 1016
          NetConnection(Connection).<init>(LogWriter, int, String, int, String, Properties) line: 322
          NetConnection.<init>(NetLogWriter, int, String, int, String, Properties) line: 208
          ClientJDBCObjectFactoryImpl.newNetConnection(LogWriter, int, String, int, String, Properties) line: 270
          ClientDriver.connect(String, Properties) line: 140
          DriverManager.getConnection(String, Properties, ClassLoader) line: 572
          DriverManager.getConnection(String) line: 218
          Derby2026LoginTimeout.main(String[]) line: 52
          In the stack above, Derby2026LoginTimeout is the repro provided in the jira. I just changed the repro's name and the jdbc url inside the repro.

          I am not sure at this point how(or if it can be done) but may be a fix would be to have the setSoTimeout be set only while the connection is being made. Once we have the connection, go back and rest the setSoTimeout to 0. I noticed following api in derby.client.net.NetAgent.java
          protected void setTimeout(int timeout)
          This api changes the timeout on socket to the passed value. I wonder if this api can be somehow used to change the timeout value to 0 after the connection has been established. As of right now, there is only one caller to NetAgent.setTimeout method and that call is from derby.client.Net.NetConnection40.isValid(int) method.

          Show
          Mamta A. Satoor added a comment - - edited The issue is setting a login timeout is also causing the queries to time out within that time. I did some debugging of the code and following is what I saw. It appears that if the user has asked for login timeout, then during the connection setup time , we call setSoTimeout on the the socket which is used for communication. The api defination for setSoTimeout api on Socket says follows public void setSoTimeout(int timeout) throws SocketException Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout. Parameters: timeout - the specified timeout, in milliseconds. Throws: SocketException - if there is an error in the underlying protocol, such as a TCP error. So, it looks like that this setSoTimeout setting is applicable not just for the login time but also for every interaction after that which in our test case includes the query execution. The code path for setSoTimeout call on socket through our connection set up is as follows Thread [main] (Suspended) NetAgent.<init>(NetConnection, LogWriter, int, String, int, int) line: 142 NetConnection.newAgent_(LogWriter, int, String, int, int) line: 1016 NetConnection(Connection).<init>(LogWriter, int, String, int, String, Properties) line: 322 NetConnection.<init>(NetLogWriter, int, String, int, String, Properties) line: 208 ClientJDBCObjectFactoryImpl.newNetConnection(LogWriter, int, String, int, String, Properties) line: 270 ClientDriver.connect(String, Properties) line: 140 DriverManager.getConnection(String, Properties, ClassLoader) line: 572 DriverManager.getConnection(String) line: 218 Derby2026LoginTimeout.main(String[]) line: 52 In the stack above, Derby2026LoginTimeout is the repro provided in the jira. I just changed the repro's name and the jdbc url inside the repro. I am not sure at this point how(or if it can be done) but may be a fix would be to have the setSoTimeout be set only while the connection is being made. Once we have the connection, go back and rest the setSoTimeout to 0. I noticed following api in derby.client.net.NetAgent.java protected void setTimeout(int timeout) This api changes the timeout on socket to the passed value. I wonder if this api can be somehow used to change the timeout value to 0 after the connection has been established. As of right now, there is only one caller to NetAgent.setTimeout method and that call is from derby.client.Net.NetConnection40.isValid(int) method.
          Hide
          Mamta A. Satoor added a comment -

          I am attaching a patch, DERBY2026_LoginTimeout_diff_patch1.txt, which is a very simple fix. Basically, after the connection has been set, I am setting the setSoTimeout on socket back to 0. Because, user intended the login time out only for the connection time and not for all the interaction between client and server. Setting the setSoTimeout on socket to 0 will make sure that we do not end up using login time out as also query time out. Please let me know if anyone has any feedback on this fix.

          I am running junit suite right now(I have intermittently seen NetworkServerControlClientCommandTest.testPing fail intermittently but it happens with and without my patch). Once junit tests run successfully, I will run derbyall and if all goes well, I will go ahead and commit the patch.

          Show
          Mamta A. Satoor added a comment - I am attaching a patch, DERBY2026_LoginTimeout_diff_patch1.txt, which is a very simple fix. Basically, after the connection has been set, I am setting the setSoTimeout on socket back to 0. Because, user intended the login time out only for the connection time and not for all the interaction between client and server. Setting the setSoTimeout on socket to 0 will make sure that we do not end up using login time out as also query time out. Please let me know if anyone has any feedback on this fix. I am running junit suite right now(I have intermittently seen NetworkServerControlClientCommandTest.testPing fail intermittently but it happens with and without my patch). Once junit tests run successfully, I will run derbyall and if all goes well, I will go ahead and commit the patch.
          Hide
          Mike Matrigali added a comment -

          The code change makes sense to me. I don't know a lot about this code, but as long as the connection is complete by the point of your added code my reading of the socket interface makes it look like this is the right change.

          some questions about testing for this issue:
          1) Do the existing tests exercise set login timeout, so that we have some coverage that your change does not break the existing logic.
          2) Are you going to add a junit test that will show the bug before your change
          and verify that it is fixed after the change?

          Does anyone know if this socket timeout stuff is used for query timeout, and if so will this change have any affect?

          Show
          Mike Matrigali added a comment - The code change makes sense to me. I don't know a lot about this code, but as long as the connection is complete by the point of your added code my reading of the socket interface makes it look like this is the right change. some questions about testing for this issue: 1) Do the existing tests exercise set login timeout, so that we have some coverage that your change does not break the existing logic. 2) Are you going to add a junit test that will show the bug before your change and verify that it is fixed after the change? Does anyone know if this socket timeout stuff is used for query timeout, and if so will this change have any affect?
          Hide
          Kathey Marsden added a comment -

          DriverManager is pretty vague, but I am getting pretty confused on the various timeout options in DataSources and Sockets. For DataSource I see:

          setLoginTimeout
          A value of zero specifies that the timeout is the default system timeout if there is one; otherwise, it specifies that there is no timeout. When a DataSource object is created, the login timeout is initially zero.

          On Socket setSoTimout I see:
          The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.

          So I guess according to spec with setLoginTimeout set, after we make the connection, it should restore things to the system default, not call setSoTimeout(0) to make it infinite but I don't actually see an option to do that with setSoTimeout on the socket.

          Furthermore, I have a report from a user using the existing code that is seeing timeouts on queries after calling setLoginTimeout(0) which I think should change things to an
          infinite timeout but does not appear to be doing so. Of course if that is the case, neither Mamta's fix nor restoring to the default after the connection would help them.

          Sorry for the rambling. I will do some experiments on my machine and hopefully get access to the user's to try and understand all this better. Any comments of pearls of wisdom in this area are welcome.

          Show
          Kathey Marsden added a comment - DriverManager is pretty vague, but I am getting pretty confused on the various timeout options in DataSources and Sockets. For DataSource I see: setLoginTimeout A value of zero specifies that the timeout is the default system timeout if there is one; otherwise, it specifies that there is no timeout. When a DataSource object is created, the login timeout is initially zero. On Socket setSoTimout I see: The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout. So I guess according to spec with setLoginTimeout set, after we make the connection, it should restore things to the system default, not call setSoTimeout(0) to make it infinite but I don't actually see an option to do that with setSoTimeout on the socket. Furthermore, I have a report from a user using the existing code that is seeing timeouts on queries after calling setLoginTimeout(0) which I think should change things to an infinite timeout but does not appear to be doing so. Of course if that is the case, neither Mamta's fix nor restoring to the default after the connection would help them. Sorry for the rambling. I will do some experiments on my machine and hopefully get access to the user's to try and understand all this better. Any comments of pearls of wisdom in this area are welcome.
          Hide
          Kathey Marsden added a comment -

          Mamta's fixes the issue with DriverManager but it is still an issue with a DataSource. See LoginTimoutWithDataSource.java.

          As an aside, I am trying to write a test to verify that setLoginTimeout does actually cause a connect to timeout and have verified this manually by using setLoginTimeout(1) and creating a new db but it seems sometimes even 1 second is enough time to create a database. I am looking for a reliable way to slow down the connect. Myrna suggested forcing a large recovery to slow things down but I would like something more predictable. Ideas welcome.

          Show
          Kathey Marsden added a comment - Mamta's fixes the issue with DriverManager but it is still an issue with a DataSource. See LoginTimoutWithDataSource.java. As an aside, I am trying to write a test to verify that setLoginTimeout does actually cause a connect to timeout and have verified this manually by using setLoginTimeout(1) and creating a new db but it seems sometimes even 1 second is enough time to create a database. I am looking for a reliable way to slow down the connect. Myrna suggested forcing a large recovery to slow things down but I would like something more predictable. Ideas welcome.
          Hide
          Lily Wei added a comment -

          I read it from the google search saying "Java NIO(nonblocking IO) and using blocking sockets is that the SO_TIMEOUT is not used anymore even if you set it." Java NIO can be switch on by use one Selector per SocketChannel and select() for OP_READ or OP_WRITE before every read or write. Will this be why infinite timeout does not work on DataSource?

          One observation: ClientDataSource. getLoginTimeout() return 10 instead of 10000 after I do ClientDataSource.setLoginTimeout(10) Is this expected? The same goes to DriverManager.

          Show
          Lily Wei added a comment - I read it from the google search saying "Java NIO(nonblocking IO) and using blocking sockets is that the SO_TIMEOUT is not used anymore even if you set it." Java NIO can be switch on by use one Selector per SocketChannel and select() for OP_READ or OP_WRITE before every read or write. Will this be why infinite timeout does not work on DataSource? One observation: ClientDataSource. getLoginTimeout() return 10 instead of 10000 after I do ClientDataSource.setLoginTimeout(10) Is this expected? The same goes to DriverManager.
          Hide
          Mamta A. Satoor added a comment -

          I am on vacation for this week and next week. Will look more into this after I am back but I did want to point out that setting the setLoginTimeout to infinite ie 0 after a user has made a connection will only affect the future connections. The existing connection which was made with a finite login timeout will continue to have that timeout property set on the socket it had used to create the connection. At least this is what I think from my research on this jira. If my interpretation is correct, then Kathey, I think my proposed fix might help them with their problem.

          Show
          Mamta A. Satoor added a comment - I am on vacation for this week and next week. Will look more into this after I am back but I did want to point out that setting the setLoginTimeout to infinite ie 0 after a user has made a connection will only affect the future connections. The existing connection which was made with a finite login timeout will continue to have that timeout property set on the socket it had used to create the connection. At least this is what I think from my research on this jira. If my interpretation is correct, then Kathey, I think my proposed fix might help them with their problem.
          Hide
          Kathey Marsden added a comment - - edited

          Attached is a patch for this issue derby-2026_diff.txt which builds on Mamta's change. There were two more instances when the soTimeout needed to be reset after completing the connection. The change Mamta made was the path for DriverManger. The other two cases were after completing the connections obtained from DataSources and also after reset of pooled conenctions. Tests have been added to ConnectTest for DriverManager and J2EEDataSourceTest for the data sources. I have not yet run regressions, but will do so tonight.. Please review

          Thanks

          Kathey

          Show
          Kathey Marsden added a comment - - edited Attached is a patch for this issue derby-2026_diff.txt which builds on Mamta's change. There were two more instances when the soTimeout needed to be reset after completing the connection. The change Mamta made was the path for DriverManger. The other two cases were after completing the connections obtained from DataSources and also after reset of pooled conenctions. Tests have been added to ConnectTest for DriverManager and J2EEDataSourceTest for the data sources. I have not yet run regressions, but will do so tonight.. Please review Thanks Kathey
          Hide
          Kathey Marsden added a comment -

          I went ahead and submitted to trunk and will leave this open while I backport to 10.5

          Show
          Kathey Marsden added a comment - I went ahead and submitted to trunk and will leave this open while I backport to 10.5
          Hide
          Kathey Marsden added a comment -

          One thing I forgot to mention on the patch was that I am a bit concerned with the length of time the new tests take to run, which is about 2 minutes because the various configurations require the long query be run 6 times. Right now I have the loginTimeout set to 10 seconds and the query to sleep 20. I am not sure the best way to speed it up and make it reliable even on slow hardware or with slow jvm options. One thought that occurred to me is perhaps I could time the length it takes for a connection and use that as a baseline.

          Show
          Kathey Marsden added a comment - One thing I forgot to mention on the patch was that I am a bit concerned with the length of time the new tests take to run, which is about 2 minutes because the various configurations require the long query be run 6 times. Right now I have the loginTimeout set to 10 seconds and the query to sleep 20. I am not sure the best way to speed it up and make it reliable even on slow hardware or with slow jvm options. One thought that occurred to me is perhaps I could time the length it takes for a connection and use that as a baseline.
          Hide
          Lily Wei added a comment -

          Predict timeout timing is always hard across platforms. Use the accurate time it takes for a connection is more efficient. However, I will recommend 30% buffer for different platform behavior.

          From looking at the change, I am assuming socket timeout is used for query timeout.
          Will it make more sense to separate LoginTimeout and query timeout value for Derby with different datasource? From NetConnection constractor path(line 206 on java/client/org/apache/derby/client/net/CetConnection.java), the driverManagerLoginTimeout is also get use as query timeout. In the future, should we need to separate these two types of timeout?

          Show
          Lily Wei added a comment - Predict timeout timing is always hard across platforms. Use the accurate time it takes for a connection is more efficient. However, I will recommend 30% buffer for different platform behavior. From looking at the change, I am assuming socket timeout is used for query timeout. Will it make more sense to separate LoginTimeout and query timeout value for Derby with different datasource? From NetConnection constractor path(line 206 on java/client/org/apache/derby/client/net/CetConnection.java), the driverManagerLoginTimeout is also get use as query timeout. In the future, should we need to separate these two types of timeout?
          Hide
          Kathey Marsden added a comment -

          Porting the patch to 10.6 I see the following timeout on a connect in a later test. I think this is because the tests I added do not correctly reset the login timeout on the DriverManager and various DataSources after running the test. I will make that change and submit shortly to trunk.

          1) testReplication_Encrypted_1_miniLoad_negative(org.apache.derbyTesting.functio
          nTests.tests.replicationTests.ReplicationRun_Local_Encrypted_1)java.sql.SQLNonTr
          ansientConnectionException: A communications error has been detected: Read timed
          out.
          at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLE
          xceptionFactory40.java:70)
          at org.apache.derby.client.am.SqlException.getSQLException(SqlException.
          java:358)
          at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
          at java.sql.DriverManager.getConnection(DriverManager.java:322)
          at java.sql.DriverManager.getConnection(DriverManager.java:273)
          at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
          ionRun.bootMasterDatabase(ReplicationRun.java:863)
          at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
          ionRun.makeReadyForReplication(ReplicationRun.java:2746)
          at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
          ionRun_Local_Encrypted_1.testReplication_Encrypted_1_miniLoad_negative(Replicati
          onRun_Local_Encrypted_1.java:132)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
          java:48)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
          sorImpl.java:25)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          109)
          at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
          ionRun.runBare(ReplicationRun.java:207)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:16)
          Caused by: org.apache.derby.client.am.DisconnectException: A communications erro
          r has been detected: Read timed out.
          at org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(NetAg
          ent.java:415)
          at org.apache.derby.client.net.Reply.fill(Reply.java:176)
          at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java
          :218)
          at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:320)
          at org.apache.derby.client.net.Reply.startSameIdChainParse(Reply.java:11
          60)
          at org.apache.derby.client.net.NetConnectionReply.readSecurityCheck(NetC
          onnectionReply.java:112)
          at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessR
          db(NetConnection.java:843)
          at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessR
          db(NetConnection.java:768)
          at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(NetConn
          ection.java:601)
          at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.j
          ava:408)
          at org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:2
          18)
          at org.apache.derby.client.net.NetConnection40.<init>(NetConnection40.ja
          va:77)
          at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConne
          ction(ClientJDBCObjectFactoryImpl40.java:269)
          at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:83)
          ... 34 more
          Caused by: java.net.SocketTimeoutException: Read timed out
          at java.net.SocketInputStream.socketRead0(Native Method)
          at java.net.SocketInputStream.read(SocketInputStream.java:141)
          at org.apache.derby.client.net.Reply.fill(Reply.java:174)
          ... 46 more

          FAILURES!!!
          Tests run: 12463, Failures: 0, Errors: 1

          Show
          Kathey Marsden added a comment - Porting the patch to 10.6 I see the following timeout on a connect in a later test. I think this is because the tests I added do not correctly reset the login timeout on the DriverManager and various DataSources after running the test. I will make that change and submit shortly to trunk. 1) testReplication_Encrypted_1_miniLoad_negative(org.apache.derbyTesting.functio nTests.tests.replicationTests.ReplicationRun_Local_Encrypted_1)java.sql.SQLNonTr ansientConnectionException: A communications error has been detected: Read timed out. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLE xceptionFactory40.java:70) at org.apache.derby.client.am.SqlException.getSQLException(SqlException. java:358) at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) at java.sql.DriverManager.getConnection(DriverManager.java:322) at java.sql.DriverManager.getConnection(DriverManager.java:273) at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat ionRun.bootMasterDatabase(ReplicationRun.java:863) at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat ionRun.makeReadyForReplication(ReplicationRun.java:2746) at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat ionRun_Local_Encrypted_1.testReplication_Encrypted_1_miniLoad_negative(Replicati onRun_Local_Encrypted_1.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 109) at org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat ionRun.runBare(ReplicationRun.java:207) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) Caused by: org.apache.derby.client.am.DisconnectException: A communications erro r has been detected: Read timed out. at org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(NetAg ent.java:415) at org.apache.derby.client.net.Reply.fill(Reply.java:176) at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java :218) at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:320) at org.apache.derby.client.net.Reply.startSameIdChainParse(Reply.java:11 60) at org.apache.derby.client.net.NetConnectionReply.readSecurityCheck(NetC onnectionReply.java:112) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessR db(NetConnection.java:843) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessR db(NetConnection.java:768) at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(NetConn ection.java:601) at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.j ava:408) at org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:2 18) at org.apache.derby.client.net.NetConnection40.<init>(NetConnection40.ja va:77) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConne ction(ClientJDBCObjectFactoryImpl40.java:269) at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:83) ... 34 more Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.derby.client.net.Reply.fill(Reply.java:174) ... 46 more FAILURES!!! Tests run: 12463, Failures: 0, Errors: 1
          Hide
          Kathey Marsden added a comment -

          Resolving this issue. I won't port it further back than 10.5 right now.

          Show
          Kathey Marsden added a comment - Resolving this issue. I won't port it further back than 10.5 right now.
          Hide
          Dag H. Wanvik added a comment -

          Did we ever make a positive test, i.e. to show that a login timeout actually does throw the expected SQLTimeoutException?
          I can't find it right now; if we don't have one I'll file an improvement issue.

          Show
          Dag H. Wanvik added a comment - Did we ever make a positive test, i.e. to show that a login timeout actually does throw the expected SQLTimeoutException? I can't find it right now; if we don't have one I'll file an improvement issue.

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Olav Sandstaa
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development