[infinispan-dev] HotRod?? [ISPN-29 and a "custom protocol"]

Galder Zamarreno galder at redhat.com
Tue Dec 8 14:36:22 EST 2009


Hi all,

I've updated with a very early draft of the hot rod protocol:
http://www.jboss.org/community/wiki/HotRodProtocol

As a reference, I've been using 
http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol to see 
what memcached did. Alex, as I emailed you yesterday, it'd be 
interesting to see what you did too.

First, several operations are still missing from the spec: remove, 
removeIfPresent, *Async ops (putAsync, removeAsync...etc), putAll, 
putForExternalRead, evict, version, name (get cache's name).

Also, I still need to think how to add flags into each operation sent 
across the network.

There're some other operations that I'm consider whether to include or 
not. Here's what I'm thinking at the moment:

- keySet, entrySet, values: I don't plan to include them since they'd be 
very expensive both from a cache iteration perspective and from sending 
that stuff back to the client.

- containsKey: I don't plan to include it, you can figure it out with 
get command.

- containsValue: No plan to include it since we don't support it.

- size, isEmpty: Maybe include them as part of stats command like 
memcached does?

Also, it might be wised to implement operations like replaceIfEquals 
using with a cas long, like memcached does 
(http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol), rather 
than sending the value cos that would be more network efficient. The old 
value could be much more longer.

Another thing to note here is that for expiry and maxIdle, I followed 
the Java TimeUnit based definition. To make it easier for client 
implementers, we could follow the memcached style, where seconds are 
used always and if the number of seconds is bigger than 30 days, those 
seconds represent UNIX time (number of seconds since 1st January 1970). 
WDYT?

Finally, memcached has this notion of getq where, as far as I can 
understand the spec, it's a quiet operation where the server holds up 
the return until you send a non quiet operation, i.e. a get or a noop. I 
need to look further into it to understand how exactly works, but it'd 
be interesting to know the thoughts of anyone who's dealt with this already.

Cheers,

On 12/03/2009 06:22 PM, Manik Surtani wrote:
> Great, thanks Alex!
>
> On 3 Dec 2009, at 05:00, Alex Kluge wrote:
>
>> Hi,
>>
>>>> I'll see what I can do about documenting it...
>>>
>>> Yeah lets do that - I would recommend using the JBoss.org
>>> wiki pages so that the designs can be distilled by all of us
>>> and then linked to from the other Infinispan design pages.
>>
>> I've started this at
>>
>>   http://www.jboss.org/community/wiki/RemoteCacheInteractions
>>
>> I will start with a description of what I have, which is a good multilevel cache implementation. Then get to a description of some of the additional motivations and requirements for a data grid, which is a bit more general, and use that to motivate changes in the protocol.
>>
>>                                                        Alex
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list