Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [DISCUSS] API changes to provide resource cleanup


Copy link to this message
-
Re: [DISCUSS] API changes to provide resource cleanup
Voting for the hammer/hacksawjimdugging. I like the concept of being to
track resources and clean them up, but the back end code isn't designed to
deal with an instance in the way we're trying to model it.
On Thu, Jan 2, 2014 at 2:46 PM, Josh Elser <[EMAIL PROTECTED]> wrote:

> Bill Slacum and I had talked about unexpected breakages in API for clients
> and internal by modifying ZooKeeperInstance (I think I might have mentioned
> it already on one of the tickets).
>
> Considering some of the other work that Mike has started on in regards to
> making an easier-to-use client API, Bill and I mused over an
> InstanceFactory notion which could wrap different Instance implementations
> for the various deployment requirements. We could leave the current ZKI
> (close to?) how it works now, lift the non thread-safe pieces to a common
> parent, and create some sort of ThreadsafeZKI.
>
> Obviously this is very hand-wavy, but I'm definitely leery to changing the
> default impl for something so prevalent as ZKI. Thinking about the problem
> with a clean slate seems best to me.
>
>
> On 1/2/14, 1:36 PM, Eric Newton wrote:
>
>> All of our current code treats the Instance like a simple record:
>>
>> * immutable, and therefore
>> * thread-safe
>> * provides several fields that describe an instance
>>
>> When I tried to add calls to close() in our own code, I found that our
>> disregard for the lifetime of an instance was implicit, and probably is in
>> all our user's code, too.
>>
>> I think if we want to do something like #1, we'll have to do so through a
>> new API, and not by changing Instance, and then deprecate Instance.  The
>> mental model is just completely different.
>>
>> -Eric
>>
>>
>> On Thu, Jan 2, 2014 at 12:47 PM, Sean Busbey <busbey+[EMAIL PROTECTED]>
>> wrote:
>>
>>  Hey Folks!
>>>
>>> We need to come to some conclusions on what we're going to do for
>>> resource
>>> clean up. I'll attempt to summarize the situation and various options.
>>> If I
>>> missed something from our myriad of tickets and mailing list threads,
>>> please bring it up.
>>>
>>> Brief Background:
>>>
>>> The existing client APIs presume that a large amount of global state will
>>> persist for the duration of a JVM instance. This is at odds with
>>> lifecycle
>>> management in application containers, where a JVM is very long lived and
>>> user provided applications are stood up and torn down. We have reports of
>>> this causing OOM on JBoss[1] and leaked threads on Tomcat[2].
>>>
>>> We have two possible solutions, both of which Jared Winick has kindly
>>> verified solve the problem, as seen on JBoss.
>>>
>>> ----
>>> = Proposed solution #1: Closeable Instance
>>>
>>> The first approach adds a .close method to Instance so that users can say
>>> when they are done with a given instance. Internally, reference counting
>>> determines when we tear down global resources.
>>>
>>> Advantages:
>>>    * States via code where a client should do lifecycle management.
>>>    * Allows shutting down just some of the resources used.
>>>    * Is already in the code base.
>>>
>>> Disadvantages:
>>>    * Since lifecycle is getting added post-hoc, we are more likely to
>>> have
>>> maintenance issues as we find other side effects we hadn't considered,
>>> like
>>> the multithreaded issue that already came up[3].
>>>    * Changes Instance from representing static configuration to shared
>>> state
>>>    * Doesn't work with the fluent style some of our APIs encourage.
>>>    * closed semantics probably aren't consistently enforced (e.g. users
>>> trying to use a BatchWriter that came from a now-closed instance should
>>> fail)
>>>
>>> To finish, we'd need to
>>>    * Verify multithreaded handling is done without too much of a
>>> performance
>>> impact[3]
>>>    * Finish making our internal use consistent with the lifecycle we're
>>> telling others to use[4]
>>>    * Possibly add tests to verify consistent enforcement of closing on
>>> objects derived from Instance
>>>
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB