Java Bugs

https://www.pongasoft.com/blog/yan/java/2011/05/17/file-dot-deleteOnExit-is-evil/

If you take a look at the javadoc for File.deleteOnExit() it clearly states:

Once deletion has been requested, it is not possible to cancel the request. This method should therefore be used with care.

It is relatively easy to overlook this kind of statement. In my case it led to a slow memory leak that was reported in glu. In the end, finding out the memory leak turned out to be relatively simple thanks to jmap and YourKit (although it seems to always be simple after the fact :)).

The piece of (groovy) code that was causing the issue was the following:

  static String cat(location) throws IOException
  {
    File tempFile = File.createTempFile("GroovyIOUtils.cat", ".txt")

    tempFile.deleteOnExit()

    try
    {
      fetchContent(location, tempFile)
      return tempFile.text
    }
    finally
    {
      tempFile.delete()
    }
  }

What the code does: it creates a temporary file, then downloads the location (URL) in this temporary file and simply returns the content as a String. In order to be safe, I called tempFile.deleteOnExit(), but as you can see the file is deleted in the finally.

Non intuitively (but to be fair as stated in the javadoc!), once deletion has been requested, there is no way to cancel it, even if you delete the file!

The implementation of java.io.File.deleteOnExit() simply keeps a list of String representing all the files that need to be deleted when the VM exits. And this list grows and grows as the cat method is called (which in this specific scenario was every 15 seconds, so the leak took many weeks to manifest itself!).

Looking back at the issue and this specific java call, I actually do not see a real use for it and I have decided to ban it from my code for several reasons as I actually think it is evil:

1. it gives you a false sense of security: “oh the VM will take care of it…” which is not true: if the VM does not terminate properly, for any particular reason (power outage, kill -9,…) then the files will simply not be deleted. If your code relies on the fact that those files should not be present on VM restart then one day you will have a nasty surprise.
2. calling this method will eventually lead to a memory leak (granted of course it is called repeatedly, even if the frequency is very slow!)

http://bugs.java.com/bugdatabase/view_bug.do;:YfiG?bug_id=4513817
https://puneeth.wordpress.com/2006/01/23/filedeleteonexit-is-evil/

Every time we use “ImageIO.write(img, “png”, outStream)” a temporary file is created, and the “deleteOnExit()” function is called on that temporary file. Every “deleteOnExit()” allocates a “struct dlEntry” in the shared “io_util.c” native source file. This “struct dlEntry” is about 1K in size, and will never be freed until the system exits, so every time we do an ImageIO.write(), we take up another 1K of memory! No package should use “deleteOnExit()” dynamically – it guarantees a memory leak.

One workaround is to disallow the use of cache files by passing false to the static ImageIO.setUseCache() method. This avoids the deleteOnExit() problems and should have little adverse effect on performance, especially in the case of server-side applications working with relatively small images. This memory leak is a major reliability issue for developers using ImageIO in their server side applications.

The worst part: the data structure is kept in native memory.If it only was in Java heap, you might be able to diagnose the problem much quicker. Since it is in native memory rather than Java heap, profiler tools will not be able to find this memory leak.

https://java.net/jira/browse/MIMEPULL-13

The method MemoryData.createNext calls File.deleteOnExit. Unfortunately, this permanently adds an entry to a list of files. In our long running server application, the end result is a significant memory leak.
In our case, we don't have much use for this call to deleteOnExit anyway, as our system already cleans up all temporary files when the server stops. So if there is no better way, I would request a simple system property to disable this call.

workaround - create SolrConverter manually
Cannot convert value of type 'org.springframework.data.cassandra.convert.CustomConversions' to required type 'org.springframework.data.solr.core.convert.CustomConversions' for property 'customConversions': no matching editors or conversion strategy found

java.lang.IllegalStateException: Cannot convert value of type 'org.springframework.data.cassandra.convert.CustomConversions' to required type 'org.springframework.data.solr.core.convert.CustomConversions' for property 'customConversions': no matching editors or conversion strategy found


org.springframework.beans.ConversionNotSupportedException: Failed to convert property value of type 'org.springframework.data.cassandra.convert.CustomConversions' to required type 'org.springframework.data.solr.core.convert.CustomConversions' for property 'customConversions'; nested exception is java.lang.IllegalStateException: Cannot convert value of type 'org.springframework.data.cassandra.convert.CustomConversions' to required type 'org.springframework.data.solr.core.convert.CustomConversions' for property 'customConversions': no matching editors or conversion strategy found