On 14 Jul 2010, at 14:08, Manik Surtani wrote:


On 14 Jul 2010, at 13:23, Mircea Markus wrote:

thanks, see bellow.
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.
done
I'm not sure I understand what the filter and exclusion parameters are about.
Filtering is about excluding from the set of entries returned by the server to the client of those filtering keys specified in the request (filter size] [filter key size 1] [filter key 1] [filter key size 2] [filter key 2]...).
A multi get, as I see is about giving a list of keys and returning them. So, why use filtering?
We need filtering because of RemoteCacheStore: it needs to implement  CacheLoader.loadAllKeys(Set<Object> keysToExclude)

Like I said (on the wiki) - this may not be needed.  See my reasons there.
Right - this should be dropped then. (unless we 


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(*) ?
Just explicit filtering: specify the keys you want to be filtered, an the way you want to filter them (inclusive or exclusive filtering)


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?
it means that only these keys are being returned form the client, if they exist. The use case is adding an RemoteCache.get(Set) method (as stated in the document). 

How do you currently handle CacheStore.get(Set keys)?

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.
that should be possible by specifying a "key size = -1" in the request - I've updated the document as that bit was missing.  

If you are using a variable length int as a field for num_keys, you won't be able to set it to -1.  vInts are unsigned.

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. "

Interesting!  looking into this right now
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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
Lead, Infinispan
Lead, JBoss Cache




_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev