accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Resource leak warnings
Date Mon, 30 Dec 2013 16:01:48 GMT
On Dec 30, 2013 10:06 AM, "Sean Busbey" <busbey+ml@clouderagovt.com> wrote:
>
> On Mon, Dec 30, 2013 at 8:57 AM, Josh Elser <josh.elser@gmail.com> wrote:
>
> > On Dec 30, 2013 9:36 AM, "William Slacum" <
wilhelm.von.cloud@accumulo.net>
> > wrote:
> > >
> > > That being said, has anyone started on the utility so we can at least
> > have
> > > a comparison/bake off?
> >
> > A utility that forcefully closes all resources to prevent a leak? I
don't
> > believe I've seen a ticket for that yet. Please make one if so.
> >
> > What do you want to compare? That the resources are cleaned up? I would
> > assume that would be a part of testing before the aforementioned utility
> > would be committed.
> >
> >
>
> 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.

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

> Since this impacts anyone working in a reusable container environment, and
> we've already had one group of users bring it up as a significant issue, I
> would vote that it should block. Non-binding, that is.

I need to re-review the changes that have been made (and not reverted). I
haven't seen things that fall outside what I would consider excessive.
We'll likely have to figure out what the best course of action is given the
final change set.

I hope was can come up with a workaround for 1.4-1.6 and target a well
thought out solution for 1.7.

>
> --
> Sean

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