Hi,
I run ClickHouse Keeper as a ZooKeeper drop-in and talk to it from the
stock Java client. Keeper implements a superset of the protocol - a
handful of extra opcodes in the 500 range: filtered list,
check-not-exists, create-if-not-exists, recursive remove, recursive
list, and a listing that returns children together with their stats and
data in one round trip.
A single request cannot be done by subclassing. Putting an arbitrary
opcode on the wire is easy enough from a subclass of ZooKeeper, but
watch registration and chroot handling are package-private, so the
subclass cannot live anywhere but org.apache.zookeeper.
The transactional path is closed harder. To put a non-builtin op into a
multi I ended up copying four client classes into my own tree and
shadowing them on the classpath, which is about as pleasant as it
sounds. The locked doors, briefly:
- Op - private constructor plus a package-private abstract withChroot,
so it cannot be subclassed from outside the file;
- MultiOperationRecord.serialize - closed whitelist, throws on
anything else;
- MultiResponse.deserialize - the same switch on the way back;
- OpResult - private constructor.
That works, but I would rather not build on it. Two questions:
1. Would you be open in principle to opening this up - some way for a
third party to define an op with its own opnum, request/response
records and result type, without editing the client or squatting
in its package?
2. If yes, would you take a PR? What I would contribute is the seam
itself plus tests - not the ClickHouse-specific operations, those
stay on my side.
To be clear, this is not a request to support ClickHouse Keeper in the
ZooKeeper client.
All of this runs today as a prototype - the four shadowed classes plus a
subclass squatting in org.apache.zookeeper - so I have a fair idea of
what the seam would have to carry.
And happy to file a JIRA if that is the better place for this
conversation.
Thanks,
Mikhail
