[JBoss JIRA] Commented: (ISPN-29) Cache server and client module
by Galder Zamarreno (JIRA)
[ 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 :(
> Cache server and client module
> ------------------------------
>
> Key: ISPN-29
> URL: https://jira.jboss.org/jira/browse/ISPN-29
> Project: Infinispan
> 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 information
> 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira