You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

We have RFCs for proposing and recording significant changes to Geode. But those only cover the span of time between the software's open-sourcing in 2015-2016 and now.

The software on which Geode is based was already mature by then. On what guiding principles is that software based?

Well, the agilist would say: read the code. That answer is unsatisfactory if we want our project to be inviting to new contributors. There's just to much code for that answer to be practical.

The purpose of this branch of the wiki is to bring together a cohesive set of pages, each illuminating a guiding architectural principle embodied in the software.

Geode Architectural Principles

The pages linked from this section are the Geode architectural principles:

  • TBD

Candidate Principles

This section functions as a list of research questions. If you are wondering about a principle add it here! If you are knowledgable (or a good researcher!) grab something from the list and flesh it out. As these are fleshed-out into pages they can move up into the architectural principles section above.

  • 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>

Structure of a Guiding Architectural Principle

Architecture Decision Records look good: https://adr.github.io


  • No labels