[jboss-dev-forums] [Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers

[manik.surtani@jboss.com]

Rebuilding the cache loader/cache server pair is definitely on the cards, and if you want to get involved you are more than welcome.

My goals for this redesign are:

1.  Treat the TcpCacheServer (TCS) as a standalone module.  I.e., it could be used directly, without the TcpCacheLoader (TCL).
2.  The TCS would be able to "speak" 3 different protocols (and should detect which protocol is in use and select the appropriate handler).
3.  These protocols are: Memcached ASCII protocol, Memcached binary protocol, as well as a custom designed binary protocol. 
4.  The first two would allow people to reuse existing Memcached client libraries with JBC.  
5.  The third one will allow us to encode additional information - such as cluster topology and failover information - when serving responses to clients that understand this.
6.  The TCL would be one such client, speaking the jbc custom protocol.
7.  Both the TCS and TCL would be heavily multithreaded, minimally synchronized, probably making use of Netty or Apache MINA as a layer over NIO sockets.
8.  The TCL should support reconnects (this is already there, some of this code could be reused)
9.  The TCL should support failover (responses from the TCS could contain piggybacked info on TCS cluster topology).  TCL would then be able to fail over to alternate TCS instances.
10.  TCL *may* even be able to support load balancing via pluggable LB policies.

Pretty big stuff.  :)

I'm not so keen on consistent hashing on the client (TCL), since with plans I have for data partitioning (JBCACHE-60) this will end up on the server side anyway.  The client can then be simpler, just selecting a server and handling failover, possibly load balancing, etc.  


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207803#4207803

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207803