Ryan Daum commented on ISPN-29:
Re #1: See point above, ConcurrentMap alone is not sufficient for atomicity of operations
for the memcached protocol for operatons like INCR, DECR, PREPEND, APPEND, and CAS. Each
requires a read followed by a write, and are stated by the protocol to be atomic
operations, i.e. the state of the given cache entry should not change inbetween the read
and the write.
If the intent is to support only a subset of the memcache protocol, i.e. get/set/delete
then you'll be fine. Otherwise, you'll need to think about how to perform locking
across operations which may correspond to multiple ops on your end.
Re: #2. lifespans and time-to-live is not the same as the flags field that memcache
specifies, which are basically meta-data for keys.
#3: What are you using for logging now? The point of the slfj4-api is precisely to avoid
dependency hell and forcing a given logging implementation, and unlike commons logging, it
does this sanely. 'tis why I chose it, anyways.
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