accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey...@clouderagovt.com>
Subject Re: Resource leak warnings
Date Mon, 30 Dec 2013 16:16:31 GMT
On Mon, Dec 30, 2013 at 10:01 AM, Josh Elser <josh.elser@gmail.com> wrote:

> On Dec 30, 2013 10:06 AM, "Sean Busbey" <busbey+ml@clouderagovt.com>
> 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.



>  > > > 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.)



-- 
Sean

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message