Page History

...

• Provide a low-latency path on par with (contemporary) competitive offerings. Give examples of key adjacent decisions supporting this one. What are we trading off here, i.e. what are we giving up in order to minimize latency?
• Provide for efficient immediate consistency. How does this shape the Geode architecture? How would it be different if we were focused only on eventual consistency?
• Geode is a framework for Java—it is not a server product.
• Geode is not opinionated—it is a toolkit that can be configured for a broad range of use cases. This is exemplified by the plethora of configuration options, topologies, and region types.
• Recycle a process instead of failing fast: Geode has an "auto-reconnect" feature and by default it is enabled. The opposite of this principle would be "fail fast". This feels like an anti-pattern and should be changed!
• Geode is implemented primarily in Java. This may be an unconscious outcome of Geode is a framework for Java above. This principle could be revisited as of 2020 (without violating that other principle) given the plethora of JVM-based languages now available.Geode implements concurrent tasks using Java Threads directly. Geode code, at every level, creates threads and creates runnables that are run on executors.
• Give every thread its own socket for P2P but pool sockets for client-server: Geode has a "conserve-sockets" setting for P2P communication. The best-practices recommendation is to turn this off. Until version 1.10, Geode had a "thread-local connections" feature on the client for client-server communication. That feature was recently removed. It seems like we are gravitating toward connection-pooling for client-server communication and away from connection-pooling for P2P communication. There is a lot of lore here about tradeoffs between resource efficiency and latency. What forces are driving the architecture at these two interfaces (client-server and P2P.)
• <your candidate principle goes here>

...