Archived

This forum has been archived. Please start a new discussion on GitHub.

Locator cache vs Connection cache

Just want to clarify some concepts.

If I set LocatorCacheTimeout=0, and I have a replica group that has a round-robin load-balancing policy and returns 1 adapter, everytime I do

proxy = communicator.stringToProxy("A_id"), I would get a different proxy, correct?

Now within a given proxy, there could be multiple endpoints. If I get the proxy using ice_connectionCached(false), then every request to the same proxy would result in a new connection establishment. If the proxy only have one endpoint, does ice_connectionCached(false) have an impact? I tried this and I turned on Ice.Trace.Network=2, I don't see connections getting dropped and reestablished on every call made on the proxy.

Assuming all the above is true, to achieve per request load balancing, we can do two things:
1) Setup a replica group, and have the client get a proxy before every request and turn off LocatorCache OR
2) Use direct proxies (without replica group) with multiple endpoint and turn off connection cache.

Which approach is more typical? or better?

If the client connects through Glacier2 how does connection caching work? Can the client still control it using ice_conenctionCached()? If I understand correctly, the real proxy is held by Glacier2 and not the client.

Thanks
Budyanto

Comments

  • benoit
    benoit Rennes, France
    Hi,
    Just want to clarify some concepts.

    If I set LocatorCacheTimeout=0, and I have a replica group that has a round-robin load-balancing policy and returns 1 adapter, everytime I do

    proxy = communicator.stringToProxy("A_id"), I would get a different proxy, correct?

    Not exactly, stringToProxy just transforms a stringified proxy into a proxy programming language object. It doesn't establish any connection (or make Ice locator calls), it doesn't select any endpoint to be used for invocations on the proxy.

    So everytime you call stringToProxy, you just create a new proxy object which has no associated Ice connection. The first call on the proxy will be responsible for selecting the endpoint to use and associating a connection with the proxy.
    Now within a given proxy, there could be multiple endpoints. If I get the proxy using ice_connectionCached(false), then every request to the same proxy would result in a new connection establishment.

    It doesn't necessarily result in a new connection establishmet. Setting ice_connectionCached(false) on a proxy just means that the proxy will lookup a connection for each request: the proxy doesn't remember (or cache ) the Ice connection it uses for a request. The Ice communicator maintains a set of opened connection so if a connection matching the selected endpoint for the proxy is already established, it will be re-used and no new connection will be established.
    If the proxy only have one endpoint, does ice_connectionCached(false) have an impact?

    For each request on the proxy, a connection will be looked-up so this can have a small performance impact. Otherwise, the request should always be sent on the same connection as if connection caching was enabled.
    I tried this and I turned on Ice.Trace.Network=2, I don't see connections getting dropped and reestablished on every call made on the proxy.

    This is expected, disabling connection caching on proxies doesn't mean that a new connection is established for each request. Connections are maintained opened by the Ice runtime even if no Ice proxies are associated to them. Connections are eventually closed by active connection management when not used anymore.
    Assuming all the above is true, to achieve per request load balancing, we can do two things:
    1) Setup a replica group, and have the client get a proxy before every request and turn off LocatorCache OR

    Creating a new proxy before each request has the same effect as re-using a same proxy with connection caching disabled. So you don't necessarily need to create a new proxy for each request, you could also always re-use the same proxy for which you have disabled connection caching...
    2) Use direct proxies (without replica group) with multiple endpoint and turn off connection cache.

    Which approach is more typical? or better?

    It really depends on your application. Using IceGrid will for sure provide more flexibility as you can easily add/remove replicas at runtime with having to worry about notifying clients as you would need to do if you were using direct proxies
    If the client connects through Glacier2 how does connection caching work? Can the client still control it using ice_conenctionCached()? If I understand correctly, the real proxy is held by Glacier2 and not the client.

    Yes, with Glacier2 things are different: glacier2 invokes on the back-end server on behalf of the client and you can't modify the proxy settings (other than with the Ice.Default.* properties) that Glacier2 uses to invoke on the back-end servers. In this situation, if you need fine control over how the requests from the client are load-balanced on the backend servers, it's best to implement a facade object in the session server: the client invokes on this object through Glacier2 and this facade takes care of all the details regarding load balancing to the back-end servers (this also simplifies your client as it doesn't have to worry about this anymore...).

    For more information on how Ice manages connections and if you didn't already have a look at them, I recommend reading the Connection Management chapter in the manual and Matthew's article in the Issue #24 of the Connections newsletter.

    Cheers,
    Benoit.
  • Thanks for the detailed answers. That really helps clarify some things.

    And thanks for the pointer to the articles. I found some other good articles in there too.

    I have a follow up question:

    In the article "Advanced use of Glacier2" (Issue 2 May 2005), it was recommended that we set a context in the callback proxy to make Glacier2 use oneway invocation to the client, to improve efficiency. I'm trying it a little differently, although I think it should also work. In the article, it was the server (ChatRoom) who's creating a new proxy (based on the proxy passed during the call to enter()) with a context that has "_fwd" set to "o". Instead I'm setting it from the client. So the callback proxy that's sent to the server already has the context set. Here's a code snippet
    Map<String, String> context = new HashMap<String, String>();
    context.put("_fwd", "o");
    ProxyHelper.checkedCast(adapter.createProxy(callbackReceiverIdent).ice_context(context)));
    

    The created proxy is then passed to the server. I'm looking at the request Id of Current on the client side. The request id is non-zero which indicates that the request made by the server is still routed by Glacier2 as a twoway. I'm wondering if I miss anything.

    Thanks
    Budyanto
  • benoit
    benoit Rennes, France
    Hi,

    Yes, proxy contexts are not transmitted over the wire along with the proxy, they are only local (like other proxy attributes such as the locator cache timeout, connection caching, etc). You should set this context on the server side instead (which is is probably better anyway as it keeps your client simple and this also makes sure the optimization works for any clients).

    For more information on which proxy attributes are marshaled over the wire, see Appendix D or the Proxy encoding section in the Ice manual.

    Cheers,
    Benoit.