<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Adding infinispan-dev in CC as these these might be of interest for other as well.</div><br><div><div>On 9 Nov 2010, at 16:03, Richard Achmatowicz wrote:</div><blockquote type="cite"><div>Hi Mircea<br><br>Thanks for the clarification on connection pooling.<br><br>One other question about HotRod concerning intelligence. My understanding is that RemoteCacheManager<br>can can be aware of:<br>- the topology of the cluster it is interacting with, by way of piggybacking topology information onto responses</div></blockquote><blockquote type="cite"><div>- the host in a cluster a (k,v) pair should reside on by way of doing its own hashing, and so can correctly<br>choose the server-side server module it should talk to directly<br></div></blockquote>both true<br><blockquote type="cite"><div><br>What wasn't clear to me was how these features were activated. The impression I got was that they are<br>activated implicitly depending on the type of cache involved:<br></div></blockquote>In the case of Java hr client they are activated by default. The reason for having these levels is for clients written in other languages. e.g. if one would want to write a client in c++ but doesn't need to be topology-aware because it uses a static ISPN cluster then no point implementing the whole protocol, but only a subset of it. </div><div><blockquote type="cite"><div>- if a client is using a replicated cache, then cluster-topology information together with load balancing will be used<br>automatically to determine which server-side server module to talk to when the client interacts with the cache<br></div></blockquote>yes. The load balancing policy can be specified through infinispan.client.hotrod.request_balancing_strategy config. Defaults to round-robin <br><blockquote type="cite"><div>- if a client is using a distributed cache, then load balancing will be ignored and hashing will be used to determine<br>which server-side server module to talk to when the client interacts with the cache<br></div></blockquote>yes<br><blockquote type="cite"><div>- if a client is using an invalidate cache ????<br></div></blockquote>same as replicated.<br><blockquote type="cite"><div>- all of this happens with no prior configuration of the RemoteCacheManager required<br></div></blockquote>yes.<br><blockquote type="cite"><div>- a RemoteCacheManager can thus be both (i) using load balancing to determine which server-side peer to interact with<br>*and* (ii) using hashing to determine which server-side peer to interact with, depending on the caches it has handed out and<br>the configurations of those caches<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote>-yes <br><blockquote type="cite"><div>Is this correct?</div></blockquote><div><br></div>All of it! </div><div>Cheers,</div><div>Mircea<br><blockquote type="cite"><div><br>On 11/09/2010 06:25 AM, Mircea Markus wrote:<br><blockquote type="cite">Hi Richard,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 8 Nov 2010, at 22:52, Richard Achmatowicz wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Mircea<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I'm looking at a javadoc for RemoteCacheManager and some of the description on the connection pooling section<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is a little unclear for me.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The way I understand it,TCP connections are established between a RemoteCacheManager instance and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a server-side HotRod server module instance, in order to pass requests executed on the client side to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the server side for processing and return the results.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The originators of the requests may be the RemoteCacheManager<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">itself, or client threads performing operations on caches they received from the RemoteCacheManager.<br></blockquote></blockquote><blockquote type="cite">yes.<br></blockquote><blockquote type="cite"><blockquote type="cite">So, if we have one client thread CT1 on the client-side, accessing a cache C provided by its RemoteCacheManager,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">RCM, and there are three nodes X,Y,Z on the server side, then we have at least three TCP connections held by the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">RemoteCacheManager, one for each node on the server-side.<br></blockquote></blockquote><blockquote type="cite">yes.<br></blockquote><blockquote type="cite"><blockquote type="cite">I'm trying to understand your definitions of the terms maxActive, maxTotal and maxIdle from the javadoc for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">RemoteCacheManager. I'm going to look at the definitions one by one:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1. maxActive - controls the maximum number of connections per server that are allocated (checked out to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">client threads, or idle in the pool) at one time.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- when you say per server, do you mean per X, Y or Z HotRod server modules on the server side?<br></blockquote></blockquote><blockquote type="cite">yes.<br></blockquote><blockquote type="cite"><blockquote type="cite">- when is a connection allocated? When a client CT1 calls RCM.getCache()? When a client CT1<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">performs an operation on a cache it has obtained? (i.e. are the TCP connections allocated per cache instance<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">or per operation?)<br></blockquote></blockquote><blockquote type="cite">Connection are pooled and reused between operations on RemoteCaches. All remote named caches (i.e. as obtained through RCM.getCache(name)) share the same connection pool. When a method a RemoteCache is called (e.g. get(k)) a connection<br></blockquote><blockquote type="cite">is taken from the pool, used for communicating with servers and then returned to pool. Due to load, the pool might be empty(all connections are borrowed) when a RC asks for a connection:<br></blockquote><blockquote type="cite">the behaviour in this case is specified by whenExhaustedAction (by default caller blocks)<br></blockquote><blockquote type="cite"><blockquote type="cite">- when is a connection released? When an operation is completed? Is this the same as becoming idle?<br></blockquote></blockquote><blockquote type="cite">A connection is released by the connection eviction thread (see timeBetweenEvictionRunsMillis):<br></blockquote><blockquote type="cite">- if minEvictableIdleTimeMillis is reached for that connection<br></blockquote><blockquote type="cite">- if the tcp connection breaks<br></blockquote><blockquote type="cite"><blockquote type="cite">- does this mean that cache instances can not concurrently use the same TCP connection? Or does this<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">mean that cache operations, even from the same cache, cannot use the same TCP connection?<br></blockquote></blockquote><blockquote type="cite">there's no relation between cache and connection. All remote caches borrow connections from the same connection pool instance, which is one/RCM.<br></blockquote><blockquote type="cite"><blockquote type="cite">2. maxTotal - sets a limit on the number of persistent connections that can be in circulation within the combined<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">set of servers<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- seems clear<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">3. maxIdle - controls the maxiumum number of idle persistent connections per server at any one time<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- seems clear<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">4. whenExhaustedAction - specifies what happens when asking for a connection from a server's pool<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and that pool is exhausted<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- again, under what circumstances do we "ask for a connection from a server's pool"?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- "the pool is exhausted" mean that maxActive has been reached, right?<br></blockquote></blockquote><blockquote type="cite">that + all connections are in-use at that moment.<br></blockquote><blockquote type="cite"><blockquote type="cite">Any help with this appreciated. Trying to figure out what I need to test with this.<br></blockquote></blockquote><blockquote type="cite">Hope it is more clear now, I'll also update the javadoc with this.<br></blockquote><blockquote type="cite"><blockquote type="cite">Richard<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><br></div></blockquote></div><br></body></html>