This is just a warning...
I noticed that org.hornetq.core.client.impl.ClientConsumerImpl uses File.deleteOnExit if session.isCacheLargeMessageClient() is true.
File.deleteOnExit() keeps a list of pathnames that need to be deleted (even if File.delete() was subsequently called).
It would be a fairly simple matter to remove a file from the delete on
exit list when it gets deleted, but that would be a violation of spec.
File.deleteOnExit says "Requests that the file or directory denoted by this
abstract pathname be deleted when the virtual machine terminates." So
just because the file is deleted does not mean that it will not get re-opened later. The File object might even get garbage collected but another of the same
name might be created later. We are obligated by the spec to remember the path
and delete a file there when the VM terminates. There is no way around the
memory leak without relaxing this spec.
The leakage is small on a per file basis, but could add up as hornetq is a long running process.
Thanks for the raising it.
I'm scheduled to do some work on Large Messages in two weeks, and I will remove the deleteOnExit from the code. I will see if there's a way around on the JDK when I get to it.. or if I will have to implement the feature myself in a way it won't leak.