[infinispan-dev] BulkGet in hotrod (ISPN-516)

Mircea Markus mircea.markus at jboss.com
Wed Jul 14 08:48:02 EDT 2010


On 14 Jul 2010, at 11:49, Galder Zamarreño wrote:

> Hi Mircea,
> 
> You should make it explicit in the title that this is a design document to avoid confusion.
> 
> I'm not sure I understand what the filter and exclusion parameters are about. A multi get, as I see is about giving a list of keys and returning them. So, why use filtering? And what type of filtering would it be? REGEX based filtering?...etc. Are you trying to use filtering as a way for clients to instruct to load all keys for example? Like get(*) ?
> 
> What does it mean that they're inclusive? Only keys that fulfill all filters will be returned? If so, what's the use case for this?
> 
> I'm also worried if this might be complicating the protocol when RCS can simply start a bunch of threads and get all the keys in paralell individually. The only thing that would be really be missing here is how to get the list of all keys stored in the server, for loadAll() calls for example.
> 
> One thing to note is that Memcached binary protocol removed support for multi-get as such. IOW, in the txt protocol, u could do: get <k1>, <k2>...etc but not any more in the binary one.
> 
> For the binary protocol, they went for a different approach based on get/getq where they pipeline requests, see "4.2.  Get, Get Quietly, Get Key, Get Key Quietly" section on: http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol
> 
> I think it's interesting to find out more about, particularly about this sentence cos I'm not sure I understand it: "You can also do the naive thing and send n pipelined get/getks, but then you could potentially get back a lot of "NOT_FOUND" error code packets. "
they have a  quiet get: getq (tailing q stands for quiet).
getq won't return anything unless a non quiet get is triggered: at this point it pulls bag everything, ignoring "NOT_FOUND" responses.
This is different from what you need as it presumes that the client knows all the keys it is interested in - not our case.
> 
> Cheers,
> 
> On Jul 14, 2010, at 9:50 AM, Mircea Markus wrote:
> 
>> Hi,
>> 
>> I've added a wiki to summarise some thoughts around how this should work: http://community.jboss.org/wiki/HotRodBulkGet
>> Can you please take a look and comment?
>> 
>> Cheers,
>> Mircea
>> _______________________________________________
>> 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




More information about the infinispan-dev mailing list