[infinispan-issues] [JBoss JIRA] Commented: (ISPN-29) Cache server and client module

[Galder Zamarreno (JIRA)]

    [ https://jira.jboss.org/jira/browse/ISPN-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12473290#action_12473290 ] 

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