Galder Zamarreno commented on ISPN-29:
I started to have a look at this and the first thing I've done is look at jmemcached
to see what it had. Here are some thoughts based on their claims and what I saw from the
source code (trunk):
Claim: "# The storage for the cache is abstracted so it should be possible to replace
it with other cache implementations (such as OSCache, EHCache, etc.) if that is
- com.thimbleware.jmemcached.Cache itself is a class and
com.thimbleware.jmemcached.CacheStorage is the interface. It looks as if CacheStorage is
the one that different providers should be implement.
- CacheStorage API says: Read and write operations need not be thread safe as the
caller (ServerSessionHandler (read CacheStorage!)) establishes its own locks.
- So, Cache has locking hardcoded (using a ReentrantReadWriteLock). No good for a
CacheStorage based in ISPN where clients shouldn't worry about locking.
- Also, CacheStorage has keys hardcoded to String. Value hardcoded to MCElement, a
Serializable representation of the value that is jmemcached specific.
- Note that MCElement contains key too, so looks like there's duplication here.
- Deleting a key from the cache is hardcoded in Cache to be done asynchronously, using
a delayed queue.
Claim: "# It uses JBoss Netty for non-blocking, scalable (Java NIO) network
- Source code is hardcoded to use Netty.
- Having talked with DML, using XNIO directly would give us better perf. Note: I still
need to play around with XNIO.
- So, using a library that is hardcoded to Netty might not be really that useful to
- The license of jmemcached is not clear from their main site
) but it appears to be Apache License 2.0
- Few unit tests (35 tests in total)
- The only The only real advantage I see to using jmemcached, is the fact that
memcached protocols (both text and binary [available since 1st March 2009:
]) have already been
implemented but JGroups has already done this, at least for the text version, so it's
not really that bigger plus.
- Code wise, I see loads of enum comparison seems to be done via if/else statements
rather than switch statements.
- jmemcached brings slf4j dependency :(
Cache server and client module
Issue Type: Feature Request
Components: Cache Server
Reporter: Manik Surtani
Assignee: Galder Zamarreno
Fix For: 4.1.0.BETA1, 4.1.0.GA
To be built on top of the cache.
Transports should be pluggable - Apache MINA, Netty, JDK7 NIO2, native, etc., but for now
just build one based on XNIO
Protocols should be pluggable - memcached text-based, custom binary with server topology
Test with various memcached clients (java and non-java)
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira