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

Quick note. You don't specify TCP/UDP, though I assume it's intended to be TCP? - DML On 12/08/2009 01:36 PM, 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. > > - 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev