This is a simple implementation that will allow for singleton synchronisation of Cassandra clusters and sessions.
Connector traits may be mixed in to any number of Cassandra tables, but at runtime, the cluster, session or ZooKeeper client must be the same.
The ClusterStore serves as a sync point for the ZooKeeperClient, Cassandra Cluster and Cassandra session triplet.
All it needs as external information is the keySpace used by the Cassandra connection.
It will perform the following sequence of actions in order:
- It will read a known environment variable, named TEST_ZOOKEEPER_CONNECTOR to find the IP:PORT combo for the master ZooKeeper coordinator node.
- If the combo is not found, it will try to use the default ZooKeeper master address, namely localhost:2181.
- It will then try to connect to the ZooKeeper master and fetch the data from the "/cassandra" path.
- On that path, it expects to find a sequence of IP:PORT combos in the following format: "ip1:host1, ip2:host2, ip3:host3, ...".
- It will fetch the ports, parse them into their equivalent java.net.InetSocketAddress instance.
- With that sequence of InetSocketAddress connections, it will spawn a Cassandra Load Balancer cluster configuration.
- This will work with any number of Cassandra nodes present in ZooKeeper, the connection manager will load balance over all Cassandra IPs found in ZooKeeper.
- After the cluster is spawned, the Store will attempt to create the keySpace if necessary, using a Cassandra Compare-and-Set query.
- It will then feed the keySpace into the Cassandra session to obtain a final, directly usable values where queries can execute.
The initialisation process is entirely synchronised, using the JVM handle before to ensure only the first thread trying to read a Cassandra Session will
cause the initialisation process to start. Any thread thereafter will simply read the initialised ready-to-use version. Any attempt to read values directly
before they are initialised will throw an EmptyClusterStoreException.
This is a simple implementation that will allow for singleton synchronisation of Cassandra clusters and sessions. Connector traits may be mixed in to any number of Cassandra tables, but at runtime, the cluster, session or ZooKeeper client must be the same.
The ClusterStore serves as a sync point for the ZooKeeperClient, Cassandra Cluster and Cassandra session triplet. All it needs as external information is the keySpace used by the Cassandra connection.
It will perform the following sequence of actions in order: - It will read a known environment variable, named TEST_ZOOKEEPER_CONNECTOR to find the IP:PORT combo for the master ZooKeeper coordinator node. - If the combo is not found, it will try to use the default ZooKeeper master address, namely localhost:2181. - It will then try to connect to the ZooKeeper master and fetch the data from the "/cassandra" path. - On that path, it expects to find a sequence of IP:PORT combos in the following format: "ip1:host1, ip2:host2, ip3:host3, ...". - It will fetch the ports, parse them into their equivalent java.net.InetSocketAddress instance. - With that sequence of InetSocketAddress connections, it will spawn a Cassandra Load Balancer cluster configuration. - This will work with any number of Cassandra nodes present in ZooKeeper, the connection manager will load balance over all Cassandra IPs found in ZooKeeper. - After the cluster is spawned, the Store will attempt to create the keySpace if necessary, using a Cassandra Compare-and-Set query. - It will then feed the keySpace into the Cassandra session to obtain a final, directly usable values where queries can execute.
The initialisation process is entirely synchronised, using the JVM handle before to ensure only the first thread trying to read a Cassandra Session will cause the initialisation process to start. Any thread thereafter will simply read the initialised ready-to-use version. Any attempt to read values directly before they are initialised will throw an EmptyClusterStoreException.