db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6094) Derby ignores DriverManager.setLoginTimeout()
Date Thu, 07 Mar 2013 13:52:13 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595880#comment-13595880
] 

Rick Hillegas commented on DERBY-6094:
--------------------------------------

Hi Dag,

Thanks for taking a look at the LoginTimeoutTest repro. Attaching a new version of the repro
which fixes that typo you found.

I agree that the result you are seeing is odd. I don't see that result myself. This is a warning
to me: when I turn this code into a regression test, it may be plagued by heisenbugs like
our other timing-sensitive network tests. This is the result I see:

Stopping server...
Starting server with timeout 10

Setting timeout 1 on local connector
    Testing LoginTimeoutTest$DriverManagerConnector( jdbc:derby://localhost:8246/memory:db1
)
        java.sql.SQLNonTransientConnectionException: SQLState = 08006. Message = A communications
error has been detected: Read timed out.
        Experiment took 1040 milliseconds.
Setting timeout 10 on local connector
    Testing LoginTimeoutTest$DriverManagerConnector( jdbc:derby://localhost:8246/memory:db1
)
        Ha! Got a org.apache.derby.client.net.NetConnection40
        Experiment took 4010 milliseconds.

Note that when I ran the experiment, the odd test case succeeded (as expected), but it took
4 seconds rather than the authentication sleep time of 2 seconds. That is because Derby does
double authentication when you create a database. I don't understand why you are seeing a
"connection refused" error after 1 second when you run that experiment. A socket timeout ought
to be reported as such, as you can see from the immediately preceding experiment on my machine.
So it seems that you are seeing some other communications failure. Are your results reproducible?

It's true that an earlier rev of the test ran the server in the same VM as the client. I thought
that would make the test run faster because I wouldn't have to keep bouncing the server. But
I abandoned that approach early on because it didn't test the case where the client and server
set different timeouts.

Thanks,
-Rick

                
> Derby ignores DriverManager.setLoginTimeout()
> ---------------------------------------------
>
>                 Key: DERBY-6094
>                 URL: https://issues.apache.org/jira/browse/DERBY-6094
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.10.0.0
>            Reporter: Rick Hillegas
>         Attachments: LoginTimeoutTest.java, LoginTimeoutTest.java, LoginTimeoutTest.java,
LoginTimeoutTest.java
>
>
> If you set a login timeout using the DriverManager, Derby ignores the setting. I will
attach a test case which shows this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message