[jira] Updated: (DERBY-3440) Run suites.All with statement pooling enabled and classify the problems occurring

["Kristian Waagan (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kristian Waagan updated DERBY-3440:
-----------------------------------

    Attachment: WithCPDS-WithStatementPooling-errors-01.txt
                WithCPDS-NoStatementPooling-errors-01.txt

13 failures when running with connections obtained from CPDS with statement pooling DISABLED:
 a) derbynet.ClientSideProperties.testConnection
    A bug in the data source implementations?
 b) jdbcapi.DatabaseMetaDataTest.testConnectionSpecific x 5
    DERBY-3431 & co
 c) jdbcapi.BlobClob4BlobTest.testClobAfterClosingConnection
    Looks like DERBY-3469, but the error happens in the embedded driver (encryption suite).
 d) jdbcapi.BlobClob4BlobTest.testBlobAfterClosingConnection
    Looks like DERBY-3469, but the error happens in the embedded driver (encryption suite).
 e) jdbcapi.J2EEDataSourceTest.testConnectionErrorEvent x 3 (different test methods)
   Looks like a bug with event handling, haven't investigated much or found JIRA yet.
 f) jdbc4.StatementTest.testIsClosedWhenClosingConnectionInInvalidState
    DERBY-3319
 g) jdbc4.ConnectionMethodsTest.testConnectionIsValid
   Looks like a bug, haven't investigated much or found JIRA yet.

I have attached the stack traces as 'WithCPDS-NoStatementPooling-errors-01.txt'.

When running with statement pooling ENABLED, I get a total of 14 failures and 4 errors.
I have fixed two of the errors and two of the failures. The last two errors are my own asserts caused by the client driver not checking the content of the columnIndexes and columnNames argument to prepareStatement.
The rest of the failures are the same as when running without statement pooling, except I don't get failure (g) above.

I have attached the stack traces (including those I have fixes for) as 'WithCPDS-WithStatementPooling-errors-01.txt'.

As a side note, I also added some simple "instrumentation" of how connections are obtained. For the statement pooling case, suites.All produced the following output:
>>> Event name : count
        conn.client.CPDS : 3076
        conn.client.DS : 336
        conn.client.Driver : 197
        conn.client.XSDS : 1188
        conn.embedded.CPDS : 5506
        conn.embedded.DS : 8056
        conn.embedded.InternalDriver : 10525
        conn.embedded.SDS : 2
        conn.embedded.XADS : 1315
        tc.openConnection():org.apache.derbyTesting.junit.ConnectionPoolDataSourceConnector : 7134
        tc.openConnection():org.apache.derbyTesting.junit.XADataSourceConnector : 122
        tc.openConnection(String):org.apache.derbyTesting.junit.ConnectionPoolDataSourceConnector : 70
        tc.openConnection(String,String):org.apache.derbyTesting.junit.ConnectionPoolDataSourceConnector : 803

I won't get into details now, but note that due to the inheritance hierarchy in the embedded driver, each connection is logged several times and the logging is not 100% accurate (some connections are denied due to to errors etc before it is logged in InternalDriver).
If I get the time, I'll produce a list of tests that are actually run with connections from CPDS.
I also have a test specifically for statement pooling, but it isn't that big (will attach it under DERBY-3329 I think).

> Run suites.All with statement pooling enabled and classify the problems occurring
> ---------------------------------------------------------------------------------
>
>                 Key: DERBY-3440
>                 URL: https://issues.apache.org/jira/browse/DERBY-3440
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Test
>    Affects Versions: 10.4.0.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>             Fix For: 10.4.0.0
>
>         Attachments: WithCPDS-NoStatementPooling-errors-01.txt, WithCPDS-WithStatementPooling-errors-01.txt
>
>
> The patches for the statement pooling feature should soon make it possible to run suites.All with statement caching enabled.
> I will post a patch that modifies TestConfiguration to return connections from a ConnectionPoolDataSource.
> There will be a substantial numbers of errors, and I hope to classify these and maybe refer to JIRA issues that will make them go away.
> I have already tried this, and ended up at around 180 failures/errors, a report will follow soon.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.