in ZooKeeper-849 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.
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 for the lookup table.
Please give me your feedback about the general idea so that I could start
Unrelated: Could some commiter please review ZOOKEEPER-837 "cyclic
dependency ClientCnxn, ZooKeeper"?
(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.)
Thomas Koch, http://www.koch.ro