Archived
About Properties For Connection Cache
Hi All~
There is "name.ConnectionCached" in "Proxy Properties".
Why not supply Ice.Default.ConnectionCached?ConnectionCached has two effects.
First, whether a proxy bind the connection used by first time invocation.
Second, whether another proxy (point to the same ice object) reuse a existing connection even if they has different endpoint set, endpoints order and selection type.
We can't let a proxy give higher priority to endpoints selection than reuse a existing connection.Trade off between load balance, invocation serialize, horizontal scale, connection reuse, collocation optimized, and fail-over become difficult and inflexibility because we can't control connection via control endpoints and it's order , especially when Glacier2 and IceStorm are participation.
For example, multi-client call multi-server via multi-Glacier2 and Glacier2 Use IceGrid as Locator.
If we want multi-server load balance and fail-over by system load, the only way i found is config below:
Glacier2 Properties:
Ice.Default.LocatorCacheTimeout = x, x must >= 0, smaller to more frequently query from locator
Ice.Default.EndpointSelection = Ordered
Ice.Default.Locator.EndpointSelection = Random
Ice.Default.Locator.ConnectionCached = 0
Ice.BackgroundLocatorCacheUpdates = 1 (to avoid invocation delay)
IceGrid Deployment Descriptors - replica group:
y must > 0 and must < num of server, This is the point and the side effect.
If glacier-A has a connection to server-A, Ice establish a new connection only when this new endpoint list from locator don't contains server-A's endpoint. so locator must not return all endpoints.
A side effect is, we can't use per-request load balance in server internal, because locator can't return all endpoints to the ice object. A sulotion is put the servant into two objectAdapter with different identity and different replica group, one for glacier, another for server internal.
Another side effect is Automatic Retries.Since locator return less endpoints, ice retry may be fail even if some server still alive.
Comments
-
Text disappears:
load-balancing type="adaptive" load-sample="5" n-replicas="y"
0 -
If client uses a replica-group, there is no change to do per-request load balancing. Only glacier2 know that endpoints list.
There is no connection disable option for those adapters go through the Glacier2 on Glacier2.0 -
client <-----> glacier2 <-----> my system <-----> another system
^
I need per-request load balancing
^
I disable locator cache, let glacier query the object's endopints every time.
And let Icegrid always return just one of endpoints (load-balancing type="adaptive")The situation is that I got load-balancing in "glacier2 <-> my system", but lost fail-over.
Because Icegrid return the same endpoint to Glacier2 when automatic retries...
I got per-request load balancing in "my system <-> another system", but ugly...There are similar situations in IceStorm.
If there is "Ice.Default.ConnectionCached", everything will be easier.
If there is "Ice.Default.ReuseConnectionButAbideByEndpointsRules", that'll be great.0 -
looks like that we have to modify the glacier2 source codes
0 -
Hi,
IceGrid shouldn't return the same endpoints on automatic retry if it detected that the server is down (i.e.: the IceGrid node hosting the server becomes un-reachable, the server crashed and can't be restarted, etc). If the server is still considered "up" by IceGrid, then yes, IceGrid might return the same endpoint ... but not necessarily (it depends on the load balancing type, when using adaptive, it will return the endpoint of a server on the least loaded node).
As I mentioned on this other post, when using Glacier2, the best is to add an extra "facade" layer between the client and the backend servers:
`client <----> Glacier2 <----> Session/Facade server <----> backend servers`
The client invokes on its session object and the session object is responsible for calling on the backend servers. The session implementation has better control on how to invoke on the backend systems. Such a pattern also allows to hide the complexity of the backend system to the client and can provide a simplified interface tailored for interactions with the client.
Cheers,
Benoit.0 -
I have used "facade" layer in the beginning, but thousands client go to the same facade server.....orz
0 -
Hi,
Typically, facade servers are "lightweight" servers which mostly forwards requests to backend systems. You can deploy several to distribute the load if necessary. A common deployment is to deploy one session/facade server per Glacier2 instance on the same machine.
Cheers,
Benoit.0
