Bug 369941

Description Onno Van den Troost 2012-01-27 10:23:49 EST

A customer reported an Out-Of-Memory error, and heapdump analysis showed that ServerCommandHandler was the main leak suspect.

Our developer already communicated with David M. about this:

<quote>
Looking at the heap dump, this part of heap occupation
is narrowed down to HashMap which stores the cancellable threads of UniversalDownloadHandler. 
The UniversalDownloadHandler instance is not removed from the HashMap soon after the download is finished.
The following actions are defined as the cancellable threads:
  Copy
  CreateFile
  CreateFolder
  Delete
  Query
  Rename
  Download
  Search
The timing when the thread instance is removed from the HashMap is the time when the thread is gone and the next cancellable command has come to the UniversalFileSystemMiner from a client.

Looking at the server log, about 15 clients were working at one process.
The total size of instances which the above HashMap has is about 150MB.
That is, about 15MB per client in average.
When all of the clients download some USS file and then works for MVS miners, all of the UniversalDownloadHandler instances are not removed.
In fact, the heap core dump said that the current thread was MVS miner.
 
After all, I think that Open RSE base should remove the  cancellable threads from the HashMap soon after the UniversalFileSystemMiner finishes the process for the corresponding command.

David,
What do you think about this problem ?
---
Completed threads are supposed to be removed from the cancellable threads HashMap on subsequent commands so I'm not sure why there would be an accumulation.  I've attached a dstore_miners.jar that automatically involves updateCancellableThreads() after download completion.
</quote>

The customer confirmed that the test fix worked.

We would like a backport of the fix to 30x and 32x.