You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been spending a lot of time lately looking at the ZooKeeper code, and there's a lot of room for improvement. For the longest time, I really couldn't understand what ZooSession is really doing that's important. After spending some more time on it, I've come to believe that it is merely allowing client object reuse for unclosed ZooKeeper objects globally. However, I believe this is no longer needed, because we are not arbitrarily constructing ZooKeeper instances through static utilities throughout our code like we may have once done.
In current Accumulo code, we now have ClientContext and ServerContext objects that maintain state for clients (AccumuloClient) and server-side processes (AbstractServer and utilities), respectively, and give a lifecycle to that state. There are only a few calls to ZooSession, and they are entirely in ZooReader and ZooReaderWriter, which are lightweight wrappers around ZooKeeper for convenient read/write operations. ZooReader/Writer are instantiated as fields inside ClientContext/ServerContext, so it is not necessary to have all this complexity.
I believe ZooSession can be removed, and ZooReader/Writer can be rewritten as decorators for a ZooKeeper that is directly stored as a field in ClientContext/ServerContext, and this would dramatically simplify much of our ZooKeeper code, as well as clean up some complexity in ClientContext/ServerContext.
Unless there's a good reason why ZooSession should stay, I intend to work on this.
The text was updated successfully, but these errors were encountered:
I've been spending a lot of time lately looking at the ZooKeeper code, and there's a lot of room for improvement. For the longest time, I really couldn't understand what ZooSession is really doing that's important. After spending some more time on it, I've come to believe that it is merely allowing client object reuse for unclosed ZooKeeper objects globally. However, I believe this is no longer needed, because we are not arbitrarily constructing ZooKeeper instances through static utilities throughout our code like we may have once done.
In current Accumulo code, we now have ClientContext and ServerContext objects that maintain state for clients (AccumuloClient) and server-side processes (AbstractServer and utilities), respectively, and give a lifecycle to that state. There are only a few calls to ZooSession, and they are entirely in ZooReader and ZooReaderWriter, which are lightweight wrappers around ZooKeeper for convenient read/write operations. ZooReader/Writer are instantiated as fields inside ClientContext/ServerContext, so it is not necessary to have all this complexity.
I believe ZooSession can be removed, and ZooReader/Writer can be rewritten as decorators for a ZooKeeper that is directly stored as a field in ClientContext/ServerContext, and this would dramatically simplify much of our ZooKeeper code, as well as clean up some complexity in ClientContext/ServerContext.
Unless there's a good reason why ZooSession should stay, I intend to work on this.
The text was updated successfully, but these errors were encountered: