Infinispan will speak 3 different protocols.
- Memcached text protocol
- Custom binary protocol (dubbed HotRod)
The purpose of this server module is two-fold. Firstly, so that Infinispan can be used as a drop-in replacement for memcached servers. Secondly, so Infinispan can leverage the plentitude of client libraries written for memcached, thereby exposing Infinispan to clients beyond just JVM languages.
The design involves a wrapper class that bootstraps a cache instance, starts a protocol parser service, and listens on a socket. Making use of executors to handle inbound connections, parsing the connections and proxying the requests to the in-VM cache.
Typically, all network communications would be behind an interface - a Transport - making it pluggable. We may ship with a default implementation
A REST protocol for interacting with the cache, making use of simple GET, PUT, REMOVE, etc commands. The detail of it needs to be designed (e.g., how parameters are passed in, lifespans, etc).
Tracking this feature here.
The REST server module would be available in 2 forms: as a WAR file that can simply be deployed in any servlet container, and as a standalone server - which would probably bootstrap an embedded servlet container and deploy the WAR file.
A custom, high-performance binary protocol (called HotRod for now) will also be written. This protocol will have all the advantages of compact streams and minimal parsing, as well as the ability to build "smart" clients which have some knowledge of the server topology and is able to direct requests to specific backend servers based on keys requested. This custom protocol will also enable "smart" clients to load-balance and failover.
TODO: create a wiki page detailing the HotRod protocol, so that others may implement clients using this as well.
Under the hood, this module will employ libraries such as JBoss Remoting to gain all the goodness of load balancing and failover already implemented in this library.
Clients for memcached already exist for Java and other languages so we won't ship these, and for the RESTful server a client won't be needed either. We will ship with a Java client for the custom binary protocol, which people can use to immediately gain the benefits of this high-performance server as well as to be used as a reference implementation for smart clients to be written for other platforms.
This is tracked under the umbrella entry in JIRA: ISPN-29, which contains links to sub-tasks.
These modules would probably exist in the source tree as
building artifacts such as