[
https://issues.apache.org/jira/browse/DERBY-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567132#action_12567132
]
Kristian Waagan commented on DERBY-3379:
----------------------------------------
I had a look at this one.
After some DRDA debugging and various ad-hoc tests, I think I have a basic idea
of what is happening.
Note that there are several problems with the current implementation.
First of all, the "No current connection" exception is thrown in the client
because the client side state of the connection is not maintained/handled
properly. The variable 'open_' in the connection is false (but
'availableForReuse' is true) and the exception is raised when you try to create
a new logical connection.
Secondly, the client driver has the same bug as the embedded driver regarding
nulling out the connection pointers.
Finally, when getting past the obstacles above, the test causes Derby to hang.
I found out that the reason is that the chaining bits indicate there is more to
come from the client, so the server doesn't send the reply.
This is in fact wrong, and both sides end up waiting for each other.
After some more testing and code review, I found out that opening a ResultSet
before closing the statement in the test makes the hang go away. This is
because the client has to send a command to the server asking it to close the
ResultSet, and this time the chaining bit is apparently set correctly.
I'm a bit unsure how to proceed with fixing this bug. I'm assuming the reset is
required, which indicates we somehow have to make sure the chaining bit of the
deferred reset is set correctly. The most obvious fix now I can see right away,
is to make sure we end the chain if there are no other commands going to the
server.
For instance, can we force the last chaining bit to indicate no chaining in
Agent.endWriteChain, or will this break something?
(transmission of large continued objects, bigger than 32K?)
Maybe we have to take the continuation bits into account as well?
If someone wants to have a closer look, the reset commands are constructed as
part of the ClientPooledConnection.close method, and the commands are pushed
onto the wire as part of Statement.close in the test
(DataSourceTest.testPooledReuseOnClose).
I haven't worked much with the client code, so some advice would be helpful.
> "No Current connection" on PooledConnection.getConnection() if pooled
> connection is reused during connectionClosed processing
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3379
> URL: https://issues.apache.org/jira/browse/DERBY-3379
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1
> Reporter: Kathey Marsden
>
> This is the client version of bug DERBY-2142. It can be reproduced by
> enabling the test, DataSourceTest.testPooledReuseOnClose() for client. I am
> opening a new issue for client as the embedded fix was backported to 10.1 and
> I am guessing the client fix won't be backported that far. Better to keep it
> as a separate issue.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
