Jordan Halterman

Copycat servers unnecessarily serialize/deserialize operations during replication. This has simplified debugging Copycat's replication protocol, but represents an unnecessary overhead. Copycat is designed as a low-level framework that should not really...

Currently, `Transport`s must implement a very specific threading model to work correctly with the Copycat server. This complexity should be moved out of the transport layer and into the Copycat...

The current implementation of Copycat's log uses in-memory indexes to support random access of entries in the log. However, this feature is a product of the evolution of the log...

The current implementation of Copycat's log does not handle concurrency well. This prevents leaders from replicating to followers in parallel and prevents log compaction processes from occurring in parallel with...

The current API used by Copycat for messaging between the client and server precludes certain optimizations. In particular, events published from servers to clients require responses that are unnecessary under...

Client session timeouts should be specified by the client when registering a session rather than provided by the cluster to the client.

When a single client is connected to the cluster and crashes, its session will not be expired until a new session is registered. This is because session expiration is dependent...

Followers should reject reads when they haven't heard from the leader for an election timeout. Once a follower's election times out, it will attempt to start a new election but...

The current implementation of linearizable semantics for clients via sessions follows the Raft dissertation precisely. All commands are logged with a `sequence` number. When a command is applied to the...

Generally speaking, the Raft algorithm reads log entries sequentially. When replicating to a follower, the leader reads some number of sequential entries, sends a request, gets a response, and continues....