[
https://issues.apache.org/jira/browse/DERBY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535566
]
Thomas Nielsen commented on DERBY-1781:
---------------------------------------
Bryan,
AFAIK the handle count on windows represents handles to both processes and
memory pages (and all other resources that you and the OS keep track of). Given
the steady increase in "surviving generations" seen in the profiler, my initial
assumption was that this was actually due to leaking memory.
DERBY-47 indeed seems like the probable fix. Thanks for keeping an eye on this
:)
I've started a longer running repro (more iterations) to see how things evolve
over time. Still a little early, but things seem to stabilize at around 20mb
heapsize and 1600 generations on the main trunk (10.4.0.0 alpha) after some
time. This is a good indication that we are actually *not* leaking memory, and
that the fluctuations we see in a limited number of repro runs are to be
expected.
I will need to compare the handle counts in the Sysinternals Process Explorer
from both 10.2.1.6 and 10.3.1.4 after running multiple iterations, before
resolving this issue.
> Process handles appear to be leaking in queries using an IN clause during
> concurrent DB access
> ----------------------------------------------------------------------------------------------
>
> Key: DERBY-1781
> URL: https://issues.apache.org/jira/browse/DERBY-1781
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.1.3.1
> Environment: Windows XP, Java 1.5.0_05
> Reporter: Mark Hellkamp
> Attachments: SqlStressTest.java
>
>
> We are currently using Derby embedded in our web application running on
> Windows. When processing multiple concurrent requests we have noticed that
> the Java process handle count continues to increase until the machine becomes
> unresponsive. I was able to isolate the problem to Derby by running the
> database in network mode in another process. Further investigation showed
> that the problem could be reproduced using a select statement that has an IN
> clause with multiple entries on the primary key column. Spawning multiple
> threads running the same query causes the handle count to increase
> considerably on the Derby process. The problem occurs in version 10.1.3.1 and
> 10.2.1.1 (even worse) in both embedded and network mode. The attached test
> program duplicates the problem. Start Derby in network mode (using
> startNetworkServer.bat) and run the enclosed test program. The handle count
> on the Derby process will increase and never go down short of restarting
> Derby. Using 10.2.1.1 the handle count for the Derby process goes somewhere
> between 1400-1500 with just two threads in my environment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
