[ https://jira.jboss.org/jira/browse/ISPN-29?page=com.atlassian.jira.plugin... ] 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 appropriate." Thoughts: - 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 I/O." Thoughts: - 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 us. Other thoughts: - The license of jmemcached is not clear from their main site (http://thimbleware.com/projects/jmemcached) but it appears to be Apache License 2.0 (http://freshmeat.net/projects/jmemcached) - 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: http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol]) 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 :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira