Versions Compared

Old Version 2

changes.mady.by.user Kirk Lund

Saved on

compared with

New Version Current

changes.mady.by.user Kirk Lund

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

1 Introduction

This document defines the feature and API enhancements for improving usability of GemFire.

2 Related Documents

  • Usability improvements

Client API and Features

High Effort:

  • Provide mechanism for clients to connect to multiple distributed systems or to allow switching from one server Pool on a Region to another and back again (different server Pools could be in different systems) [Effort: High]
  • Allow client queues to failback from one server back to the original server when it comes back online [Effort: High]
  • Allow client to failover to another cluster and then to failback to the original cluster when connectivity is restored [Effort: High]

Medium Effort:

  • Creation and usage of Proxy Regions which delegate fully to server [Effort: Medium] 
    • Make this similar to what's in the C#/C++ native client which provides "tethered" and "untethered" Region Views [Effort: Medium/Hard]
    • Note: We also have peer-to-peer Proxy Regions so do we extend this to include peer-to-peer as well for uniformity?

Very Low Effort:

  • ManagementService API for invoking GFSH commands on server (allows deprecation of DynamicRegionFactory) [Effort: Very Low]

Cache API and Features

Medium/Hard Effort:

  • New operations over WAN: removeAll/destroyAll, clear, transactions, invalidate* (*NOTE: invalidate is not supported by client-server which WAN uses) [Effort: Medium/Hard]
  • Provide cleaner mechanism for peer nodes to connect as client to other DS without hacky workarounds for Region name collisions [Effort: Medium/Hard]
  • Cleanup interaction between WBCL and CacheLoader/CacheWriter to avoid GET that loads from RDB resulting in WBCL writing to RDB (WBCL is very old and only understands create, update, destroy – really needs the newer ops to fix it) [Effort: Medium/Hard]

Medium Effort:

  • GetAll optimization for PartitionedRegions so that single bulk get requests are sent to each Bucket node for peers as well as Java and native clients [Effort: Medium]
  • New Region operation: Region#removeAll(Collection<?> keys) and Region#destroyAll(Collection<?> keys) [Effort: Medium]
  • Improved cache callbacks for bulk ops that are invoked once with all the keys (especially CacheLoader and CacheWriter for getAll and putAll) [Effort: Medium]

Low Effort:

  • Provide a non-deprecated way to create subregions [Effort: Low]
  • Deprecate DataPolicy#PRELOADED [Effort: Low]
  • Deprecate or remove external API for BridgeServer endpoints [Effort: Low]
  • Allow infinite chaining (wrapping) of callback args for Cache operations such as PUT (currently only allow one wrapped callback arg) [Effort: Low]

New APIs and Features

Medium Effort:

  • Complete logging overhaul - control log levels by Component/Subsystem, support SLF4J/Log4J syntax and appenders, cleanup Alerts (which messages, frequency, etc) [Effort: Medium]
  • System event API (can be used by client or over WAN by peer in other system, register for notification about any number of systems). *NOTE: this almost seems to belong under Management/Monitoring. Events to support as listed by Suds: [Effort: Medium]
    • 1> New WAN site has come online/WAN site is unreachable
    • 2> Region creation/ region destruction
    • 3> Peer joined/ Peer left
    • 4> Client joined/ Client left
    • 5> Required role available/ Required role unavailable
    • 6> Locators available/ System running without any locators.
    • 7> User configurable elements (like exchange connections or feeds being available in the system or not)?
    • 8> WBCL endpoint available/unavailable

Low Effort:

  • Lifecycle callback API (especially important for CacheServers) [Effort: Low]

Feature Compatibility

Medium Effort:

3 Terminology

4 Architectural Description

4.1 Client API

This section defines changes to the Client API with an emphasis on how Regions are accessed or created on a server.

4.1.1 Creation of Proxy Regions

Add new createProxyRegion(String) and createProxyRegion(String, Pool) methods to Client Cache:

 

Code Block
languagejava
Region customersProxy = c.createProxyRegion("customers"); 
Region ordersProxy = c.createProxyRegion("orders", serverPool);

The createProxyRegion will fail if the Region does not exist on any of the default pool's servers. This operation will always succeed if the Region is defined on at least one of the servers in the distributed system. It will not matter if the Region is available on the server that the client connects to. The server will automatically proxy all requests to the appropriate server(s).

TODO: This method can be invoked multiple times to create multiple proxies with the same name from the same client - or - should allow each thread to have its own ClientCache?

Clients can currently create a client Region that does not exist on any server (yet). We will change this and require that the servers are up and their regions are available before the client starts creating its Regions. A create on a client will fail unless the Region already exists on at least one server.

Additional API support:

 

Code Block
languagejava
Region customersProxy = c.createProxyRegion("customers"); 
Region customersProxyAlso = regionService.getRegion("customers"); 
Region parentProxy = customersProxy.getParentRegion(); 
Set<Region> subproxies = parentProxy.subregions(true); 
Set<Region> rootProxies = regionService.rootProxyRegions();

We'll add RegionService#rootProxyRegions() to return a Set of all root level proxy Regions.

RegionService#getRegion(String) will change to return a proxy Region or regular Region if either exists.

Region#getParentRegion() and Region#subregions(boolean) will be changed to return a proxy Region if the Region of context is a proxy Region.

The following methods will be deprecated. The preferred means to get similar information will be to create a proxy Region which will delegate such method calls to the server:

  • Region#keySetOnServer
  • Region#containsKeyOnServer

4.1.2 Additional Support for Proxy Regions

Proxy regions currently perform operations locally. This will be changed to always send the operations to the server. This will change the following operations:

  • Region#getParentRegion maybe
  • Region#getAttributes maybe
  • Region#getAttributesMutator maybe
  • Region#getStatistics maybe
  • Region#localInvalidateRegion noop
  • Region#localDestroyRegion noop
  • Region#close maybe
  • Region#saveSnapshot this might already work
  • Region#loadSnapshot this might already work
  • Region#getSubregion maybe
  • Region#createSubregion maybe
  • Region#subregions maybe
  • Region#getEntry
  • Region#create (will now fail it exists on server)
  • Region#put (will now return old value)
  • Region#localInvalidate noop
  • Region#localDestroy noop
  • Region#keySet
  • Region#values
  • Region#entrySet
  • Region#getUserAttribute maybe
  • Region#setUserAttribute maybe
  • Region#isDestroyed
  • Region#containsValueForKey
  • Region#containsKey
  • Region#getRegionDistributedLock maybe
  • Region#getDistributedLock maybe
  • Region#becomeLockGrantor
  • Region#localClear noop
  • Region#containsValue
  • Region#isEmpty
  • Region#size
  • Region#putIfAbsent
  • Region#remove(key, value)
  • Region#replace

We should discuss if the "local" methods are of any use to a client since it is unclear what server they will be performed on.

Currently operations that are sent to a server must go to the correct server that owns a resource. This will be changed so that the server that a client sends an operation to will automatically forward it to its peer (who may not even have a cache server running) that owns the resource. This will be done for all region ops and queries.

4.1.3 Server Management Service

As introduced in the MBean Federation Spec, the entry point to GemFire Management is through interface ManagementService:

Code Block
languagejava
ManagementService service = ManagementService.getManagementService(cache);

When a ClientCache is used as the argument to ManagementService#getManagementService(Cache), it will create a version of the ManagementService which will delegate all operations to the server group the client is connected to. Usage of this ManagementService will utilize the client connection to the server to delegate to the ManagementService on a server.

4.1.2.1 Creating Regions on a Server

GFSH and the JMX APIs will support creating regions on the server. The client can create regions on a server group by using its ManagementService to execute GFSH commands on the server using ManagementService#processComand(String). Using this same API, the client can create or manage anything on the server group(s) its connected to.

DynamicRegionFactory should be deprecated in favor of using the new Management API.

4.2 Cache API

4.2.1 Subregion Creation

Currently no API exists that lets you create a subregion using ClientRegionFactory or RegionFactory. The createSubregion methods on Region all take the old RegionAttributes which is created using the deprecated AttributesFactory. Region#createSubregion will be deprecated if it's not already.

A new createSubregion(Region parent, String name) method will be added to both ClientRegionFactory and RegionFactory. If the parent Region does not exist an exception will be thrown.

...