[
https://jira.jboss.org/jira/browse/ISPN-29?page=com.atlassian.jira.plugin...
]
Ryan Daum commented on ISPN-29:
-------------------------------
* remember jmemcached is still pre 1.0, and is under active development, so nothing is
written in stone.
* I inherited the code base from another author, though it has changed radically since
then. Many things about the design that I don't like are products of that.
* it's a side project for me, and I do not currently have it in any production
systems at my Day Job (an earlier version was used at my previous job), so it gets less
love that it could. Other people are using it. It's being used a lot for integration
tests. Still, it is under active development and getting better.
Re #1 (locking): The choice was made to do locking further up the call chain because I had
intentions at the time of potentially introducing the ability to chain or sequence cache
storages together, which would require one lock for the entire operation against all
storage engines. Further I had some notions of adding transactional (commit/rollback)
style semantics at the protocol level. Should I do that, I felt there would be some
rather explicit locking behaviours required, and it would be better off managed by Cache.
But the most important reason that Cache performs the locking is that some operations
(incr, decr, cas, prepend, and append) combine reads and writes into one atomic operation.
So in this case there are 3 possible options:
* Re-implement all these operations for every storage engine.
* Add "lock/unlock" methods to the storage engine.
* Lose atomicity on these operations.
If you have other suggestions, I'm open to them. In any case, maybe your storage would
sit at the level of Cache (which could be made into an interface or abstract), not a
CacheStorage implementation.
#2 (String/MCElement storage): The protocol really dictates this. Firstly, in the protocol
all keys are just strings and can't be anything else. Secondly, every element can have
storage flags stored along with it, as well as its timeout. This basically requires that
either the value be encapsulated in something or these attributes be external to the
value. It's just easier to do the former.
#3 (asynchronous deletes): This is incorrect, only delayed removes use the delayed
asynchronous queue. Deletes with no delay time attached are removed instantaneously.
#4 (hardcoded to netty): It took me one day to switch from MINA to Netty; so while I am
not sure I truly see the advantage of using raw NIO or XNIO, it certainly is possible and
if you know NIO well, it wouldn't take long. That said, I'm not sure why you would
do this? Do you have benchmarks to backup your performance claims? And why would a JBoss
product have a problem with a Netty dependency?
One of my goals has been to get the protocol decoding/encoding abstracted out enough that
I could do unit testing of it (right now there's just integration tests), but it's
difficult and time consuming.
#5 (license): The license is Apache 2.0, there's nothing unclear about it. Also since
your comment, the main site has switched now to a google code project.
#6 (jgroups impl of the protocol): Looking at the jgroups implementation of the
protocol... It's not complete or correct. There's more to the protocol than sets
and gets. You can reinvent the wheel and write the protocols yourself, but ... why?
#7 Enum comparisons: The big if/else chain isn't sexy, but switch statement in Java is
braindead. In particular, GET, GETS, and a number of others all take variations of the
same logic; switch would be ungainly here. You could argue (as someone else has) that this
should be a polymorphic method call per operation, but I think this would be overkill.
#8 slf4j: What's wrong with slf4j? I hope you're not suggesting commons-logging...
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