Hi Thomas, Can you please comment on the usefulness of the path class? As I see it, sharing path objects for similar prefix is probably a little hard. It would be good to get some stats on how much memory footprint change happens with the path class you propose (reusing prefixes) and just raw bytes? That would probably help in making a decision on whether to have such a class or not in the server.
Thanks mahadev On 12/20/10 8:36 AM, "Thomas Koch" <[email protected]> wrote: > Hi, > > in ZooKeeper-849[1] I proposed the introduction of a Path class and also > provided a patch. However this patch has rightfully been rejected with the > objection, that this represenation of paths at the server side would consume > too much memory. > > [1] https://issues.apache.org/jira/browse/ZOOKEEPER-849 > > Now I've a few ideas to still get a Path class and still save memory: > > - PathElement is a valid identifier for a Path level. PathElement holds a > reference to Byte[] without ever leaking this reference. Byte[] is UTF-8 > encoded. If you ever want to "see" the PathElement, it'll get converted to > String. However most accesses to a PathElement a comparissions. > > - Path holds a List of PathElements. Concatenating this List with > PATHSEPARATOR ("/") produces the Path > > - Path's Ctor is Path(List PathElement), convenience factories > PathFactory.create(String|Byte[]) can be provided. > > - A special factory for PathElement caches PathElements it already created to > reuse them. Thus two different Paths /a/b/c and /a/b/d will share the same > PathElements "a" and "b". Not only will common prefixes be shared, but two > paths /a/b/.lock and /c/d/.lock can share the same PathElement ".lock". > > - The lookup table for PathElement reusal may of course not prevent unused > PathElements from being garbage collected by holding a strong reference to > them. Thus we could use java.lang.ref.SoftReference[2] for the lookup table. > > [2] > http://download.oracle.com/javase/1.5.0/docs/api/java/lang/ref/SoftReference.h > tml > > Please give me your feedback about the general idea so that I could start > implement it. > > Unrelated: Could some commiter please review ZOOKEEPER-837[3] "cyclic > dependency ClientCnxn, ZooKeeper"? > > [3] https://issues.apache.org/jira/browse/ZOOKEEPER-837 > > (I'll also come back to work on Netty, but working on Netty requires full and > long concentration, while I can hack on other things in shorter breaks.) > > Best regards, > > Thomas Koch, http://www.koch.ro >
