This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata


Geode provides a FunctionService. Currently this FunctionService is defined to be static. In order to remove the "static-ness" of the FunctionService it is required to be made available from the Cache in a similar fashion as the RegionFactory.

The current FunctionService, currently exposes functionality that encompasses both client/server interaction and peer-to-peer (server-side), which can be confusing to users wanting to use the service.


The FunctionService refactor requires that the Geode is split into two distinct modules:

  • server cache
  • client cache

Currently, both the client and server cache code resides in the same file (GemFireCacheImpl). Without the clear distinction of client or server cache code, the splitting of client and server function service code is unclear and complex.


The current FunctionService provides 3 different services:

  • Function administration
  • Function invocation from a Geode client
  • Function invocation from a Geode server

Having the FunctionService being responsible for three distinct areas of responsibility makes it really hard to extend and maintain the code base.

In order to have a more concise service the proposal is to:

  • Separate the client and server function service implementations into distinct classes
  • Move the function administration to be a server-side function only.
  • Move the FunctionService from static access to instance-based access, like RegionFactory being accessed from Cache.

As can be seen in the below class diagram, the FunctionService is split into 3 key areas:

  • Common code
  • Server code
  • Client code

The FunctionServiceBase is shared by both the server and client function service. The client function service exposes only client-side function services:

  • onServer
  • onServers
  • onRegion

The server function service will expose:

  • onMember
  • onMembers
  • onRegion

The different function service implementations will be responsible for its area of expertise. The client function service would not know about server-side services and would not expose functionality that cannot be used.

 butavailable for


 The exposing of the FunctionService from the Cache would be fairly simple. As can be seen below, this can be achieved fairly simply. In addition to this work, the FunctionService static invocation can be kept (for deprecation period purposes) by using the static lookup Cache.getAnyInstance() and then looking up the relevant FunctionService off the Cache.


The current limitation that the client cache and server code is not separated, forces the following architecture. The cache will have to distinguish between a client and server function service. In addition to this extra logic, the ClientFunctionService and ServerFunctionService should effectively marked as Deprecated from the day they are introduced, as they would ideally only be FunctionServices and not specific to client or server.




  • No labels