<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>We have had a short discussion on putAll, getAll. I’m pushing the info here</div><div><br></div><div><br></div><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> getAll and putAll and nothing more than a glorified sequential call to get / put in a for loop.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The execution of gets and puts in parallel for it costs o(n) network trip in latency rather than o(1).<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">How could we improve it ?<br></blockquote>Historically getall and putall were not intended as hotrod operations and were actually implemented only to honor the map interface.<br>The most we can do RPC wise to optimize these operations is to group all keys mapping to the same server node into a single request. That would reduce the number of RPCs, but in big O talk it would still be O(numKeys). Executing them in parallel sounds like a good idea to me. Curious to hear other thoughts on this. Galder?<br></blockquote><br>So there are actually three improvements:<br><br>* getall and putall as hotrod operations (no matter how that will be implemented by the server itself)<br>Galder, is it possible in current HR design to execute requests in parallel, without consuming one thread for each node? That was something my async client should solve, but afaik it's not possible without substantial changes, and we were rather targetting that for future JDK 8 only client.<br></blockquote><br>Doing that it’s 1/2 of the story, because as I’ve already explained in Wolf’s efforts around putAll, the Netty server implementation just calls to Infinispan synchronous cache operations, which often block. So, using an async client will get you 1/2 of the job done. The way to limit the blocking is by limiting that blocking, e.g. splitting keys and sending gets to nodes that own it would mean the gets get resolved locally, similar thing with puts but as Bela/Pedro found out, there could be some blocking still.<br><br><blockquote type="cite">Anyway, we could route the HR request to the node with most matching keys.<br></blockquote><br>I don’t think that’s a good idea.<br><br>The best option is to take all keys, divide them by server according to hashing and send paralell native Hot Rod getAll operations contain N keys requested to each server. The same thing for putAll.<br><br>I’ve create a JIRA to get getAll/putAll implemented in the Hot Rod 2.0 timeframe: <a href="https://issues.jboss.org/browse/ISPN-4752">https://issues.jboss.org/browse/ISPN-4752</a><br></div></body></html>