accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: Resource leak warnings
Date Mon, 30 Dec 2013 17:52:55 GMT
I've been working on some of the (hopefully) well-thought-out solution for
this - see ACCUMULO-2103. There I only worked on ZooSession, which lies
beneath all of the connection-based issues. The changes are isolated enough
that I think they could be added before 1.7, but it would be OK to let the
wait. Subject to others' reviews and all that, absolutely.

I've been calling the "utility" The Hammer, and I freely release the name
for others to use.

Bill H.


On Mon, Dec 30, 2013 at 11:01 AM, Josh Elser <josh.elser@gmail.com> wrote:

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



-- 
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -

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