[
https://issues.apache.org/jira/browse/DERBY-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6094:
---------------------------------
Attachment: derby-6094-01-ac-enforceDriverManagerLoginTimeout.diff
Attaching derby-6094-01-ac-enforceDriverManagerLoginTimeout.diff. This is the
first rev of a patch to fix this issue. The new regression test is vacuous and
needs to be beefed up with the actual test cases from the repro. I am attaching
this patch because I would like to get advice and early feedback from the
community.
At a high level, the patch does the following:
1) Enforces login timeouts on the embedded driver and data sources.
2) Makes client-side login timeouts conform to the JDBC 4.2 spec. That is,
makes them raise SQLTimeoutException rather than the less refined
SQLTransientException.
3) Adds a debug flag so that JUnit tests can be run with login timeouts set.
I would like the community's feedback on the following issues:
A) Login timeouts are NOT implemented for CDC/FP 1.1. This is because I used
java.util.concurrent classes to implement login timeouts and those classes are
not available on CDC/FP 1.1. I think that it should be possible to implement
login timeouts using the Thread support in FP 1.1, but I think that the
java.util.concurrent approach is going to be easier to understand and maintain
and likely to be more robust. If someone cares about login timeouts on CDC/FP
1.1, please speak up. We can log another JIRA for adding that feature. Note
that I'm not volunteering to do that work: it's not an important platform to me.
B) I am not sure what to do about Thread interrupts incurred during a timed
login attempt. I would like advice from the experts on Derby interrupt
handling. The attached patch simply wraps the interrupt exception in a
SQLException. But maybe the right thing to do is to retry the login attempt
until the timer expires. Or something else. I tripped across this problem while
running InterruptResilienceTest with login timeouts. When I run that test like
this...
java -Dderby.tests.login.timeout=10 junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest
...I get errors in testRAFReadWriteMultipleThreads. It looks to me like the
following is happening: A WorkerThread catches an interrupted lock exception,
which it expects will happen from time to time. The WorkerThread then goes on
to create a new connection but gets another interrupt before the login timeout
expires.
Touches the following files:
------------------
M java/build/org/apache/derbyBuild/splitmessages.java
M java/engine/org/apache/derby/impl/jdbc/SQLExceptionFactory40.java
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
M java/client/org/apache/derby/client/am/SQLExceptionFactory40.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/ErrorCodeTest.java
New SQLState for login timeouts. This is wrapped in a SQLTimeoutException on
Java 6 and higher.
------------------
M java/engine/org/apache/derby/jdbc/InternalDriver.java
M java/engine/org/apache/derby/jdbc/Driver169.java
M java/engine/org/apache/derby/jdbc/Driver20.java
The guts of (1). This is where the java.util.concurrent classes are used to
enforce login timeouts for the embedded driver.
------------------
M java/engine/org/apache/derby/impl/jdbc/LOBStoredProcedure.java
M
java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java
M java/engine/org/apache/derby/impl/db/SlaveDatabase.java
M java/engine/org/apache/derby/jdbc/EmbeddedBaseDataSource.java
M java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
M java/engine/org/apache/derby/catalog/SystemProcedures.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/tools/RollBackWrappingWhenFailOnImportTest.java
The changes to the embedded driver resulted in an api change which percolated
through the classes above.
------------------
M java/client/org/apache/derby/client/net/NetConnection.java
This is the enforcement of (2), the raising of SQLTimeoutException on the
client when the login timeout expires.
------------------
M java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java
M java/testing/org/apache/derbyTesting/junit/DataSourceConnector.java
M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java
M java/testing/org/apache/derbyTesting/junit/XADataSourceConnector.java
M java/testing/org/apache/derbyTesting/junit/JDBCDataSource.java
M
java/testing/org/apache/derbyTesting/junit/ConnectionPoolDataSourceConnector.java
M java/testing/org/apache/derbyTesting/junit/Connector.java
The changes for (3). Adds a new debug flag: derby.tests.login.timeout. You can
set this to an integer, the length in seconds of the login timeout which you
want to apply to all connection attempts. I have run the full JUnit suite with
this flag set to 10. The tests run cleanly except for the following problems:
i) The errors in InterruptResilienceTest described above.
ii) I had to comment out NativeAuthenticationServiceTest. By itself, this test
runs fine with derby.tests.login.timeout=10. However, when running the full
JUnit suite with derby.tests.login.timeout=10, NativeAuthenticationServiceTest
fails and its failure then chokes the rest of the suite. I need to investigate
what's going on here.
------------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/_Suite.java
A
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/LoginTimeoutTest.java
This is the shell of a new test which will contain the cases from the repro.
> 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: derby-6094-01-ac-enforceDriverManagerLoginTimeout.diff,
> 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
