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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...