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 Threaded View
Accumulo >> mail # dev >> Resource leak warnings


Copy link to this message
-
Re: Resource leak warnings


On 12/30/13, 11:16 AM, Sean Busbey wrote:
> On Mon, Dec 30, 2013 at 10:01 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
>
>> On Dec 30, 2013 10:06 AM, "Sean Busbey" <busbey+[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> There's no ticket yet. Jared Winick, the creator of the utility to test
>> the
>>> close() based solution, mentioned in chat that he could do it this week.
>>> I'll circle back with him and get a ticket made so that either he or I
>> can
>>> get it done.
>>>
>>
>> Oh, that's different than what I thought was being talked about. I thought
>> be "utility", it referred to a not-yet-written class for Accumulo which
>> forcefully terminates the zoo* and thrift resources beneath Instance that
>> may otherwise leak when a close is not called.
>>
>> Utility as you use it makes me think you're just referring to testing the
>> code in a container to make sure it actually works.
>>
>>
>
> Correct, that is the utility previously discussed, which is what I presume
> Bill was talking about.

Ok. I'll watch for a ticket to come through.

>>   > > > I assume this is going to block  1.6.0/1.5.1.
>>>>>
>>>>
>>>> Only if we decide it should :). It's one of those things that has
>> likely
>>>> bit people for quite some time. It's up to us to decide if it's severe
>>>> enough that we should try to get it fixed before making another
>> release.
>>>>
>>>
>>>
>>> Actually, this should block 1.6.0, 1.5.1, and 1.4.5 since once published
>>> we'll be stuck with the API change.
>>
>> By that argument, the change shouldn't even be in 1.4 or 1.5. But...
>>
>>
>
> We've already discussed the API impact of this to death. The consensus each
> time eventually comes to the conclusion that there always should have been
> a way to clean up, the lack of it is a bug, and the impact is severe enough
> that we need to break forward compatibility. (a side effect of of the
> discussion is usually that our versioning numbers are broken.)

Sorry, that was a bit tongue-in-cheek :) (I guess that got lost in the
mail-server). I agree on all parts.
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