[infinispan-dev] Hot Rod - pt3

[Alex Kluge]

Hi,

  I hope you have all enjoyed the holiday season.

  The protocol is an interesting read. There are a few things that stand
 out.

  - No events. I used events, that is asynchronous messages originating
    from the server when certain conditions are met, to notify clients
    that data was written to the server.  This was mostly driven by the
    need to notify an L1 cache of a write to the cache server. It would
    be good to allow for this usage in this protocol. Note that this is
    another case where the op code is useful to have as part of the
    message.

  - What happens if the key or the value is not text? I have a way of
    representing the data to allow for a wide variety of data types,
    even allowing for arrays or maps. This will make the protocol more
    complex, but the assumption that the data is a string is rather
    limiting. This is already sketched out in the wiki.

  - Is the full message size still there as a header field? Is this
    necessary? It precludes you from generating messages where you
    don't know the full size of the message beforehand. For example,
    in the future you might want to write a map of the data in the
    cache. I do this, and can chunk the data, thus allowing me to send
    an arbitrarily large map. This becomes, to put it mildly, difficult
    if you need the size of the request as a header field.

                                  Thanks,
                                       Alex

--- On Mon, 12/21/09, Manik Surtani <manik at jboss.org> wrote:

> From: Manik Surtani <manik at jboss.org>
> Subject: Re: [infinispan-dev] Hot Rod - pt3
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Date: Monday, December 21, 2009, 5:36 AM
> 
> On 21 Dec 2009, at 11:08, Galder Zamarreno wrote:
> 
> > Hi all,
> > 
> > Re: http://community.jboss.org/wiki/HotRodProtocol
> > 
> > First, I've made the corresponding changes based on
> the feedback I got 
> > from pt2. This included reducing the response header
> since clients are 
> > already aware of what they sent, addition of topology
> view id to to non 
> > dumb requests and further specification in responses
> when topology 
> > changes have happened...etc.
> > 
> > I've also added flags to the request header that allow
> sending 
> > Infinispan flags like: skip cache store, zero lock
> acquisition 
> > timeout...etc.
> 
> > Note that I've noted this as being N * 1 byte where
> each byte represents 
> > a flag. However, I think this could maybe be sent more
> efficiently by 
> > using XOR, i.e.
> > 
> > 0x00 -> no flag
> > 0x01 (0000 0001) -> zero lock acquisition
> > 0x02 (0000 0010) -> cache mode local
> > 0x03 (0000 0011) -> zero lock acquisition + cache
> mode local
> > 0x04 (0000 0100) -> skip locking
> > ...etc.
> > 
> > With 2 bytes, we could implement 16 Flags, we
> currently 11. However, we 
> > could use vint as well, making sure that the most
> significant bit does 
> > not mean anything flag wise. Iow, with vint, in 1 byte
> we'd be able to 
> > define 7 diff flags. Thoughts?
> 
> +1
> 
> > I've also added the quit command that disconnects
> clients.
> 
> Does this have any effect on the servers?
> 
> > Finally, as far as I'm concerned, the specification is
> complete. I'm 
> > leaving the quiet commands out of this initial scope
> (see 
> > http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol).
> 
> > Remember that quiet commands could be used so that the
> server buffers 
> > responses and only when you send a non-quiet command,
> the server replies 
> > with all the pending answers.
> > 
> > As you can see at the bottom of the wiki, I've added a
> local only put 
> > request/response example so that readers get an idea
> of what a full 
> > command looks like. I had received some feedback from
> readers saying 
> > that it was difficult to understand how it all fit
> together.
> 
> The examples look good, however I would not use the
> LOCAL_ONLY flag since that flag really only has meaning in a
> p2p context.  In a client-server context, this flag is
> useless, and probably meaningless.  I would suggest a
> different flag for the example, e.g., ZERO_LOCK_TIMEOUT.
> 
> > I'll probably add a couple more examples for
> non-so-dumb and clever 
> > request/responses but I'll held them until we have a
> final round of 
> > feedback and people can indicate whether they want any
> other examples 
> > appearing in the wiki.
> > 
> > Cheers,
> > -- 
> > 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
>