Home | About | Sematext search-lucene.com search-hadoop.com
 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.