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

Galder Zamarreno galder at redhat.com
Thu Dec 10 07:23:23 EST 2009 


On 12/09/2009 01:31 PM, Manik Surtani wrote:
>
> On 8 Dec 2009, at 19:36, Galder Zamarreno wrote:
>
>> 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.
>
> Yes, I think this is unnecessary.
>
>> - containsKey: I don't plan to include it, you can figure it out with
>> get command.
>
> This would be much cheaper than a GET, from a network overhead perspective.

Hmmm, good point, particularly if what's retrieved is long. I'll add a 
containsKey op.

>
>> - containsValue: No plan to include it since we don't support it.
>
> Agreed.
>
>> - size, isEmpty: Maybe include them as part of stats command like
>> memcached does?
>
> Perhaps.
>
>> 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.
>
> Not sure I understand.  So we have 2 replace methods (thanks to ConcurrentMap) - replace(k, v) which succeeds if k is mapped to something, and replace(k, v1, v2) which succeeds if k is mapped to v1.  From what I see, only the former is supported by memcached's binary protocol and not the latter.  Are you suggesting supporting the latter in HotRod?

I'm suggesting supporting both actually.

replace(k, v) which succeeds if k is mapped to something - that's the 
same as memcached's replace command. I plan to support that.

replace(k, v1, v2) is what memcached does with 'cas' but instead of 
passing the old value, it passes the cas id, which is 8 bytes at the 
most. The old value could be a lot longer. In ConcurrentMap, replace 
works by passing the old value.

I think, to save network space, I think we should implement it the way 
memcached does. IOW, whenever something gets stored, it's stored with a 
cas id and this can later be used to replace a value, only of the cas is 
the one as we've passed.

In the txt protocol, I implemented the cas id using System.nanoTime().

>
>> 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?
>
> This is done to reduce bytes on the wire, since expressing something in millis often means extra bytes and often meaningless since network latency can be worth several hundred millis already.  So it makes sense for the protocol to express this in seconds.  Not sure I understand your comment re: seconds>  30 days.  Are you referring to the time being treated as relative to the UNIX epoch [1] as opposed to relative to the current time snapshot?

Indeed, when you pass a number of seconds that is bigger than 30 days, 
memcached understands it as the offset from 1/1/1970. Otherwise, if 
below 30 days, it thinks it's relative to the current time.

Good point about sending anything below seconds, it's wasteful and 
netwrok latency probably invalidates. Assuming we only allowed, seconds, 
minutes, hours, and days as time units, we'll be saving space compared 
to memcached.

I'm not sure of the frequency of hours/days as time units, so I'd 
inclined to only support seconds and use the same algorithm as memcached 
simply, as this reduces complexity of existing clients that might be 
used to memcached protocol.

>
> [1] http://www.techmount.com/index.php/20040830/epoch-time-unix-time-stamp
>
>> 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
>> _______________________________________________
>> 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