[
https://issues.apache.org/jira/browse/DERBY-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600499#action_12600499
]
Kristian Waagan commented on DERBY-3596:
----------------------------------------
- 1) I moved the reset to before "if (appRequester != null)". It should be true
for the shortest time possible, but it must survive for a few iterations in the
processCommands loop after it has been set to true.
- 2) Sorry, I was at bit unclear. If you look at the end of the method
processCommands, you see this inside a SanityManager.DEBUG block:
if (!this.deferredReset && pbsd != null) {
...
SanityManager.ASSERT(!pbsd.isModified(),
This assert fails because of the connection reset I do. When the PBSD is
written, we're on track again and the flag can be reset and we execute the
assert again for later iterations in the processCommands loop. This workaround
is required due to the "hackyness" of the fix...
- 3) No, I don't believe it is entirely safe to skip the user/password check.
However, that code is what creates the new connections, which is what we want
to avoid. The credentials are verified by actually connecting to the database.
Some options:
a) Make an extra connection attempt to verify credentials.
b) Hang on to the credentials made during the initial connection and see if
they have changed for the deferred resets.
Note that our driver had the functionality to change the credentials, but
it doesn't anymore. So I suppose the ability to exploit this depends on if a
malicious client can "take over the TCP-IP pipe" and act as the initial user.
The new user credential won't take effect.
For the general case, this will cause some overhead, and it is my opinion
that the driver shouldn't send this "reconnection sequence" at all. I'll try to
implement option b) in the next patch, along with some more comments and
references to the Jira issue.
> Creation of logical connections from a pooled connection causes resource leak
> on the server
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-3596
> URL: https://issues.apache.org/jira/browse/DERBY-3596
> Project: Derby
> Issue Type: Bug
> Components: Network Client, Network Server, Performance
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: complex-fix-heap.png, ConnectionPoolingBug.java,
> derby-3596-1a-complex_approach.diff, derby-3596-1b-complex_approach.diff,
> derby-3596-2a-simple_approach.diff, derby-3596-3a-test_cleanup.diff,
> nofix-heap.png, simple-fix-heap.png
>
>
> When using ClientConnectionPoolDataSource and connection pooling, a new
> connection / transaction is created for every new logical connection, and the
> resources are not freed / cleaned up in the server. They are not even cleaned
> up when the physical connection (ClientPooledConnection) is closed.
> A logical connection is obtained by invoking
> ClientPooledConnection.getConnection().
> I have observed that if you run the repro enough times against the same
> server, the number of transaction in the transaction table will be reduced
> now and then. I believe this is garbage collection, but I have not
> investigated the problem enough to tell for sure what's going on.
> I have also seen some locks not being freed, causing timeouts in some
> applications. I don't have a repro for the lock problem at this time, but it
> is very likely related to this issue.
> Note that XA connections are handled differently on the server, and do
> probably not have this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
