-
1. Re: Bulk Get from Remote Cache
There's no bulk get, but you can call RemoteCache.getAsync(key) which returns a org.infinispan.util.concurrent.NotifyingFuture (extends java.util.concurrent.Future). So, if you wanna retrieve multiple keys in parallel, just call multiple time getAsync() and when you need the values, just call Future.get(), or attach a FutureListener to the NotifyingFuture to get notified when the value is ready.
See http://docs.jboss.org/infinispan/5.1/apidocs/org/infinispan/client/hotrod/RemoteCache.html and
http://docs.jboss.org/infinispan/5.1/apidocs/org/infinispan/util/concurrent/NotifyingFuture.html
-
2. Re: Bulk Get from Remote Cache
Added an FAQ entry for this: https://docs.jboss.org/author/pages/viewpage.action?pageId=15532052
-
3. Re: Bulk Get from Remote Cache
ok, But dont you think the cost of doing multiple gets are more than a doing a single get(List). We could avoid network latency..
-
4. Re: Bulk Get from Remote Cache
since you won't wait for the first get to be completed before sending the next one, you're avoiding network latency.
Consider that at the network level close enough messages to the same node are likely to be aggregated by the transport (at Jgroups level or even lower on the stack), and also that each get() operation might need to be sent to a different address.
-
5. Re: Bulk Get from Remote Cache
Sanne, JGroups has nothing to do here. It's down to the TCP layer in the Hot Rod client which would fire these in paralell.
-
6. Re: Bulk Get from Remote Cache
Does that mean , When we fire offf Multiple Asynch "gets" to Hot Rod Server, the server will somehow figure out to package this in "one or more " Units and send back the results to the Hot Rod Client (Or are we assuming that the TCP layer at the OS level agregates these packets? ).
-
7. Re: Bulk Get from Remote Cache
Messages are not aggregated on the client and the server will deal with them independently.
Whether the TCP layer on the client or server aggregates the packets will be down to the tcp_nodelay settings. Both the Hot Rod server and client by default do tcp_nodelay, so they'll send packets as soon as they're available. If tcp_nodelay is disabled, TCP packets are batched but the latency of response increases.
-
8. Re: Bulk Get from Remote Cache
We could probably see some performance improvement if the Infinispan server packs up the results for Bulk get () and send them back to the client as a Map or a List. This could be more reliable and will offer better control than relying on the underlying TCP layer.
I am thinking something like this.
List results = cache.get(List of keys);
Any thoughts on this?
-
9. Re: Bulk Get from Remote Cache
I'm not sure that's necessarly a performance improvement. Maybe in a single node, it'll give a bit more performance, but in a distributed infinispan cluster, each key might be located in different nodes, so it's simply better to do them in paralell and let the hashing logic in the client direct the individual get operations to the nodes that own that data.
We're open though to contributions, so if this is something you feel it's important for you, have a go, it's open source . Then you can give us some numbers to see when/how it makes sense to use get(K...) as opposed to paralellising them with getAsync().
-
10. Re: Bulk Get from Remote Cache
True, for 2GBx100 Node cluster this may not transform into an performance improvement. I was thinking more on the lines of 100GBx2(or 4) Nodes Supported by some "OFF HEAP" Container Spilling over to High Perf PCIE-SSD based storage. When each business operation involves thousands of gets,may be we could see some gains. I will try to give this a go and post some numbers.