Topic
  • 9 replies
  • Latest Post - ‏2012-12-11T06:14:49Z by Erwin_Karbasi
Erwin_Karbasi
Erwin_Karbasi
186 Posts

Pinned topic ObjectGrid connection pool

‏2012-10-27T08:14:37Z |
Hello Masters,

We'd like to manage ObjectGrid objects connection pool in the client side to avoid unnecessary access to the server for each CRUD operation against the Grid.

Currently, we maintain pool of ObjectGrids on the client, fill it on initialize of the client but we don't figured out how to refresh this pool and maintain the pool after any disconnection of the server (containers/catalogs). We should remember that we also have near cache and far cache.

In order to notify about server down we have an async job that check the availability of the server and send alarm if the connection is down by trying to reconnect to the server and getting the ObjectGrid.

We have opened PMR about this issue and we have got advice to use JMX, but there is MBean for each catalog and container that we should to analyze to get the availability of the server. As i figured out there is not one MBean that can return the server availability.

We are looking for the best practices/direction for implementing above feature.

Your direction/best practices/insight would be highly appreciated.

Thanks in advance,
Erwin
Updated on 2012-12-11T06:14:49Z at 2012-12-11T06:14:49Z by Erwin_Karbasi
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: ObjectGrid connection pool

    ‏2012-11-30T09:11:25Z  
    Hello All,

    We have some misunderstandings regarding client grid access.
    As we understand, following is the functions that WXS client perform in order to access the grid server:

    The grid client begins its access to the grid by obtaining a routing table from the catalog service.
    Given an object to access, the client calculates the key’s hash code, divides that by the number of partitions,
    and the remainder is the number of the partition containing the object.
    The routing table enables the client to locate the partition’s primary shard, which contains the desired object.
    In the event of a container failure, or redistribution of partitions due to a change in grid container membership,
    the client will obtain an up-to-date routing table from one of the grid catalog servers when the next client request fails due to incorrect
    routing table content.

    When a client is unable to get a response from any the containers hosting a shard from its routing table,
    the client will contact the catalog service again.
    If the catalog service is not available, the client fails.

    Clients have minimal contact with the catalog service after the routing table is obtained, and network traffic is minimized when shards move, both of which enhance linear scalability.

    A single JVM can host many ObjectGrid instances, we are using blueprint prototype scope for txcallback bean in the objectgrid.xml Grid's definition.

    Each primary shard placed in a JVM has its own ObjectGrid instance.
    A JVM acting as a client to a remote ObjectGrid uses an ObjectGrid instance returned from the connect method's ClientClusterContext to
    interact with that Grid.
    After we obtain a specific ObjectGrid instance, then any subsequent getSession calls will returns Sessions for that ObjectGrid instance.

    According above description, does it make sense to store objectGrids pool in the client for accessing the server Grid?
    I'm asking it because as per above description each primary shard has its own objectGrid instance so if I store spicific instances in the pool it does not sure that next time I want to access the grid server I need the same objectGrid instance on the same specific shard.

    Is my above concern realistic or I have wrong hypothesis?

    I'd appreciate if you could clarify above description and shed some light on the client access flow.

    Thanks in advance,
    Erwin
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-04T18:56:44Z  
    Hello All,

    We have some misunderstandings regarding client grid access.
    As we understand, following is the functions that WXS client perform in order to access the grid server:

    The grid client begins its access to the grid by obtaining a routing table from the catalog service.
    Given an object to access, the client calculates the key’s hash code, divides that by the number of partitions,
    and the remainder is the number of the partition containing the object.
    The routing table enables the client to locate the partition’s primary shard, which contains the desired object.
    In the event of a container failure, or redistribution of partitions due to a change in grid container membership,
    the client will obtain an up-to-date routing table from one of the grid catalog servers when the next client request fails due to incorrect
    routing table content.

    When a client is unable to get a response from any the containers hosting a shard from its routing table,
    the client will contact the catalog service again.
    If the catalog service is not available, the client fails.

    Clients have minimal contact with the catalog service after the routing table is obtained, and network traffic is minimized when shards move, both of which enhance linear scalability.

    A single JVM can host many ObjectGrid instances, we are using blueprint prototype scope for txcallback bean in the objectgrid.xml Grid's definition.

    Each primary shard placed in a JVM has its own ObjectGrid instance.
    A JVM acting as a client to a remote ObjectGrid uses an ObjectGrid instance returned from the connect method's ClientClusterContext to
    interact with that Grid.
    After we obtain a specific ObjectGrid instance, then any subsequent getSession calls will returns Sessions for that ObjectGrid instance.

    According above description, does it make sense to store objectGrids pool in the client for accessing the server Grid?
    I'm asking it because as per above description each primary shard has its own objectGrid instance so if I store spicific instances in the pool it does not sure that next time I want to access the grid server I need the same objectGrid instance on the same specific shard.

    Is my above concern realistic or I have wrong hypothesis?

    I'd appreciate if you could clarify above description and shed some light on the client access flow.

    Thanks in advance,
    Erwin
    Any help please?
  • SystemAdmin
    SystemAdmin
    1485 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-04T21:10:11Z  
    Hello All,

    We have some misunderstandings regarding client grid access.
    As we understand, following is the functions that WXS client perform in order to access the grid server:

    The grid client begins its access to the grid by obtaining a routing table from the catalog service.
    Given an object to access, the client calculates the key’s hash code, divides that by the number of partitions,
    and the remainder is the number of the partition containing the object.
    The routing table enables the client to locate the partition’s primary shard, which contains the desired object.
    In the event of a container failure, or redistribution of partitions due to a change in grid container membership,
    the client will obtain an up-to-date routing table from one of the grid catalog servers when the next client request fails due to incorrect
    routing table content.

    When a client is unable to get a response from any the containers hosting a shard from its routing table,
    the client will contact the catalog service again.
    If the catalog service is not available, the client fails.

    Clients have minimal contact with the catalog service after the routing table is obtained, and network traffic is minimized when shards move, both of which enhance linear scalability.

    A single JVM can host many ObjectGrid instances, we are using blueprint prototype scope for txcallback bean in the objectgrid.xml Grid's definition.

    Each primary shard placed in a JVM has its own ObjectGrid instance.
    A JVM acting as a client to a remote ObjectGrid uses an ObjectGrid instance returned from the connect method's ClientClusterContext to
    interact with that Grid.
    After we obtain a specific ObjectGrid instance, then any subsequent getSession calls will returns Sessions for that ObjectGrid instance.

    According above description, does it make sense to store objectGrids pool in the client for accessing the server Grid?
    I'm asking it because as per above description each primary shard has its own objectGrid instance so if I store spicific instances in the pool it does not sure that next time I want to access the grid server I need the same objectGrid instance on the same specific shard.

    Is my above concern realistic or I have wrong hypothesis?

    I'd appreciate if you could clarify above description and shed some light on the client access flow.

    Thanks in advance,
    Erwin
    Hi Erwin,
    The statement "Each primary shard placed in a JVM has its own ObjectGrid instance." is talking about server side ObjectGrid instances (One per shard).
    The client side ObjectGrid instance for your grid is excluded from this statement.
    There's one of client side ObjectGrid instance for each client to the grid.

    Fred
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-04T23:59:29Z  
    Hi Erwin,
    The statement "Each primary shard placed in a JVM has its own ObjectGrid instance." is talking about server side ObjectGrid instances (One per shard).
    The client side ObjectGrid instance for your grid is excluded from this statement.
    There's one of client side ObjectGrid instance for each client to the grid.

    Fred
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
    Hi Fred,

    So is it make sense to store ObjectGrid pool in the client side for improving performance?
    And how can I sync those instances with the server side ObjectGrid?

    Thanks,
    Erwin
  • SystemAdmin
    SystemAdmin
    1485 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-05T15:06:45Z  
    Hi Fred,

    So is it make sense to store ObjectGrid pool in the client side for improving performance?
    And how can I sync those instances with the server side ObjectGrid?

    Thanks,
    Erwin
    Hmm... I'm not sure I'm exactly understanding the question correctly. Let me try.

    There's no need to "sync" the client object grid instance with the server side. The client side object grid is your API handle to all the server side shards and it handles communication and keeping data up to date. Its just the API representation of the grid (and obviously holds client maps which may have near caches).

    As far as caching it goes, you can think of the ClientClusterContext as your connection. ObjectGrid client instances are already cached in the ClientClusterContext. When you use ObjectGridManager.getObjectGrid(ClientClusterContext, *), either a new client object grid is created, OR the existing one is retrieved from the ClientClusterContext.

    You can keep the ClientClusterContext around and simply keep using it to retrieve the already existing client side ObjectGrid by name using ObjectGridManager.getObjectGrid(ClientClusterContext, String)

    Fred
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-06T10:52:18Z  
    Hmm... I'm not sure I'm exactly understanding the question correctly. Let me try.

    There's no need to "sync" the client object grid instance with the server side. The client side object grid is your API handle to all the server side shards and it handles communication and keeping data up to date. Its just the API representation of the grid (and obviously holds client maps which may have near caches).

    As far as caching it goes, you can think of the ClientClusterContext as your connection. ObjectGrid client instances are already cached in the ClientClusterContext. When you use ObjectGridManager.getObjectGrid(ClientClusterContext, *), either a new client object grid is created, OR the existing one is retrieved from the ClientClusterContext.

    You can keep the ClientClusterContext around and simply keep using it to retrieve the already existing client side ObjectGrid by name using ObjectGridManager.getObjectGrid(ClientClusterContext, String)

    Fred
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
    Hello Fred,

    Thanks a lot for clarification.
    As per following thread in order to prevent reconnect to server on each operation it's better to reserve the objectGrid instance in the client side. So as per your answer it does not boost performance (preventing too much superfluous connection to remote grid).

    As you advise it's better to reserve the ClientClusterContext in the client in order preventing unnecessary reconnection.

    We'd like to know whether we need to cache/reserve objectGrid/ClientClusterContext instance in the pool to preventing reconnection to the grid and does it boost any performance?

    Thanks,
    Erwin
  • jhanders
    jhanders
    261 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-06T13:00:52Z  
    Hello Fred,

    Thanks a lot for clarification.
    As per following thread in order to prevent reconnect to server on each operation it's better to reserve the objectGrid instance in the client side. So as per your answer it does not boost performance (preventing too much superfluous connection to remote grid).

    As you advise it's better to reserve the ClientClusterContext in the client in order preventing unnecessary reconnection.

    We'd like to know whether we need to cache/reserve objectGrid/ClientClusterContext instance in the pool to preventing reconnection to the grid and does it boost any performance?

    Thanks,
    Erwin
    Erwin,

    There is no need to maintain a pool of ClientClusterContext or client ObjectGrid instances. You should be able to have a singleton scoped to your application. A single client ObjectGrid instance can be used by multiple threads because each thread gets its own Session from the ObjectGrid. Having more client ObjectGrid instances will not boost performance. It could actually do the opposite depending on your scenario.

    If you are constantly doing ObjectGridManager.connect()/disconnect() you will end up hurting performance for sure since you will be going through all the steps of configuring the client side ObjectGrid over and over. This is the reason for maintaining a reference to the ClientClusterContext and client ObjectGrid so you don't need to connect over and over again. The discussion in the thread you reference refers to where a user was not caching the ClientClusterContext and the client ObjectGrid and were constantly doing ObjectGridManager.connect() and not doing the ObjectGridManager.disconnect() which caused the memory to grow until they went out of memory.

    I hope that clear things up. If you have additional question let us know.

    Jared Anderson
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-06T23:26:14Z  
    • jhanders
    • ‏2012-12-06T13:00:52Z
    Erwin,

    There is no need to maintain a pool of ClientClusterContext or client ObjectGrid instances. You should be able to have a singleton scoped to your application. A single client ObjectGrid instance can be used by multiple threads because each thread gets its own Session from the ObjectGrid. Having more client ObjectGrid instances will not boost performance. It could actually do the opposite depending on your scenario.

    If you are constantly doing ObjectGridManager.connect()/disconnect() you will end up hurting performance for sure since you will be going through all the steps of configuring the client side ObjectGrid over and over. This is the reason for maintaining a reference to the ClientClusterContext and client ObjectGrid so you don't need to connect over and over again. The discussion in the thread you reference refers to where a user was not caching the ClientClusterContext and the client ObjectGrid and were constantly doing ObjectGridManager.connect() and not doing the ObjectGridManager.disconnect() which caused the memory to grow until they went out of memory.

    I hope that clear things up. If you have additional question let us know.

    Jared Anderson
    Thanks a lot for your clear description.

    As i understood from documentation if I want to receive notification (and send alarm) that the Grid is down I should use JMX and monitoring the grid's catalog/containers from the client.
    There is not any listener/notification in the client (ObjectGrid) that indicates the grid unavailable.

    Thanks,
    Erwin
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: ObjectGrid connection pool

    ‏2012-12-11T06:14:49Z  
    Thanks a lot for your clear description.

    As i understood from documentation if I want to receive notification (and send alarm) that the Grid is down I should use JMX and monitoring the grid's catalog/containers from the client.
    There is not any listener/notification in the client (ObjectGrid) that indicates the grid unavailable.

    Thanks,
    Erwin
    Your assistance would be highly appreciated.