Creating or updating a grid

Use the Grid management API to create or update a grid.

Procedure

Open a command prompt and run a REST call via cURL.
To create a grid:

curl -k -u "xsadmin:xsadmin4Me!"
https://<hostname.domain.com>:9445/wxsadmin/v1/grid/{gridname}
-H "Content-Type:application/json" 
-d@inputdata.json 
-X POST
To update a grid:

curl -k -u "xsadmin:xsadmin4Me!" 
https://<hostname.domain.com>:9445/wxsadmin/v1/grid/{gridname} 
-H "Content-Type:application/json" 
-d@inputdata.json 
-X PUT
where
  • "xsadmin:xsadmin4Me!" specifies the administrator user ID and password for XSLD.
  • https://<hostname.domain.com>:9445/wxsadmin/v1/grid/{gridname} is the URL that represents the fully qualified host name and port number of the cache member group. It also contains the context root for the Operational REST server and the REST call to create a data grid.
  • {gridname} is part of the REST call that specifies the name of the data grid you want to create.
  • The inputdata.json file must be created and included in the following JSON content as part of the REST payroll to run this task command, for example:
    
{
  "description": "sync grid for testing",
  "gridType": "Custom",
  "templateName": "MyCustomGridTemplate",
  "ownerName": "xsadmin",
  "groupName":"Developers",
  "useAuthentication": true,
  "useAuthorization": true,
  "gridCapacity": "100",
  "useCapLRUEvictor": false,
  "transactionTimeout": "30",
  "numPartition": "37",
  "numSyncReplicas": "1",
  "numAsyncReplicas": "0",
  "timeToLive": "0",
  "lockTimeout": "15"
}
Notes
  • gridType specifies the type of grid being updated. Valid values are Simple, Session, DynaCache and Custom. You cannot change the type of grid. This parameter will be ignored by the grid update operation.
  • templateName specifies the name of the custom grid template to be used. This attribute is needed only when gridType is Custom at grid creation time.
  • ownerName specifies the username of the user who owns the grid.
  • groupName specifies the name of the group which has full permission to the grid. This attribute is optional at grid creation time, and will be ignored by grid update.
  • useAuthentication specifies if authentication (user/password login) should be turned on for this grid
  • useAuthorization specifies if authorization (permission management) should be turned on for this grid. Note that if authorization will be disabled if authentication is disabled.
  • gridCapacity specifies the maximum capacity of the grid in megabytes. Note that the usage of the grid is an estimation on the key and value objects only, overhead like grid metadata is not taken into account. The specified grid capacity limit will be divided by the number of partitions in the grid, and will be used as the primary shard capacity. Notice that if user data isn't evenly distributed across the grid, or if the size of the data varies a lot, some partitions might reach the limit earlier than the others.
  • useCapLRUEvictor specifies the use of an LRU (Least Recently Used) eviction policy to free up some space when partition capacity limit is reached. If LRU eviction is not enabled, the grid will reject new entries once the capacity limit is reached.
  • transactionTimeout specifies the transaction timeout in seconds
  • numSyncReplicas specifies the maximum number of synchronous replicas
  • numAsyncReplicas specifies the maximum number of asynchronous replicas
  • timeToLive specifies in seconds how long each map entry is present. The default value of 0 means that the map entry is present forever, or until the application explicitly removes or invalidates the entry. Note that this is a map level settings, and only the maps with non-zero settings in the template will be updated with the specified value.
  • lockTimeout specifies the lock time out for the backing maps in seconds.
    Note: Properties gridCapacity,useCapLRUEvictor and timeToLive are not supported in case of DynaCache Grid.
The output from this REST API is the task ID that is being run for this task command:
Output: {"taskid":3}

You can check the running task progress and task status by calling the following REST API from the joining cache member:


curl -k -u "xsadmin:xsadmin4Me!" 
https://jsmith.abc.com:9445/wxsadmin/v1/task/3
or

curl -k -u "xsadmin:xsadmin4Me!" 
https://jsmith.abc.com:9445/wxsadmin/v1/task/3/status

Where "3" is the task ID returned from the running task command.