On Dec 30, 2013 10:06 AM, "Sean Busbey" <[email protected]> wrote: > > On Mon, Dec 30, 2013 at 8:57 AM, Josh Elser <[email protected]> wrote: > > > On Dec 30, 2013 9:36 AM, "William Slacum" < [email protected]> > > 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
