[
https://issues.apache.org/jira/browse/DERBY-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6167:
--------------------------------------
Attachment: derby-6167-1a.diff
The attached patch makes the timeout argument passed to Future.get() the time
remaining instead of the total timeout, so that it doesn't wait too long if it
wakes up because of an interrupt.
The repro now behaves more as one would expect:
failed to get connection: java.sql.SQLTimeoutException: Login timeout exceeded.
getConnection took 10235 ms
failed to get connection: java.sql.SQLTimeoutException: Login timeout exceeded.
getConnection took 10002 ms
All the existing regression tests ran cleanly with the patch.
I'm not planning to add a regression test case for this bug, for the following
reasons:
a) It's a corner case bug with small consequences (only timing, no errors or
wrong results).
b) Writing a test case that's able to reliably distinguish between the bug and
the test machine being slow, requires the use of a relatively high login
timeout. Adding, say, half a minute to every run of the regression test suite
to verify the fix of such a minor issue seems too much to be justified.
c) The test case will have to interrupt the thread that is waiting for a
connection. Each time we add a test case that interrupts a thread, we have to
spend much time stabilizing the test suite afterwards because of strange
failures that start popping up on some platform/JVM combinations. I don't think
a test case for this issue is worth that effort.
> Interrupt restarts clock for login timeout
> ------------------------------------------
>
> Key: DERBY-6167
> URL: https://issues.apache.org/jira/browse/DERBY-6167
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.10.1.1
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Labels: derby_triage10_11
> Attachments: derby-6167-1a.diff, InterruptDuringConnect.java
>
>
> If a login takes time, and the thread that's blocked in Driver20.timeLogin()
> is interrupted, it will call Future.get() again with the same timeout value.
> This means that interrupting a getConnection() call will not make it
> terminate faster, as one might expect. Instead, it restarts the timeout clock
> and makes it terminate later than if it had not been interrupted.
--
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
