Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HDFS >> mail # dev >> Release of Decompressor resources in CodecPool


+
lars hofhansl 2012-12-25, 07:11
Copy link to this message
-
Re: Release of Decompressor resources in CodecPool
I think that you're right.  It looks like BuiltInGzipDecompressor,
which is marked as DoNotPool, ends up owning some JNI-managed
resources.  In this case, just relying on the GC to get around to
calling the finalizer isn't a great idea.  I think you should open a
JIRA.

cheers,
Colin
On Mon, Dec 24, 2012 at 11:11 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> In CodecPool.returnDecompressor, should we call Decompressor.end() in the "DoNotPool" case?
> Otherwise end() is only by finalize(), which is pretty terrible.
>
> -- Lars
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB