How to code listeners using Declarable

Products

• VMware Tanzu Gemfire

Issue/Introduction

This article describes some pitfalls and recommendations when coding listeners.

Environment

Resolution

It is possible to define a listener and have it work well, and then, when the server is restarted, see the following exception:

gfsh> start server --name=Server1 --classpath=/home/company/product/simulator/lib/somelibrary-0.1.0.jar --include-system-classpath=true
Starting a GemFire Server in /home/exodus/gemfire/vq/bin/1DataServer...
The Cache Server process terminated unexpectedly with exit status 1. Please refer to the log file in /home/exodus/gemfire/vq/bin/1DataServer for full details

The CLASSPATH variables are already defined as environment variables.

To solve this, make sure your AsyncEventListener implements Declarable if you intend to declare the OperationAsyncEventListener in the cache.xml file.

More generally, the rule of thumb is that any classes you register directly in the cache.xml file (e.g. PartitionResolver, Event Handlers, Functions, etc.) absolutely must also implement Declarable, whether you intend to pass arguments to it or not. This a good idea even if you register via the gfsh command, as this usually turns into an entry in the cluster configuration cache.xml file, which could cause it to work initially, yet fail on a successive startup.

Using SDG to eliminate declarable components

If you use Spring Data Geode (SDG), you can forgo the necessity of having your application-specific components and Geode plugins implement interfaces such as Declarable simply so they can be used in the cache.xml. In this case, you only need to implement the interface that actually matters (e.g. CacheListener, AsyncEventListener, etc.). In addition, SDG affords you the ability to use Java config as well, leveraging Spring's other capabilities beyond what Geode offers by itself. Refer to this link for more information.

Additional Information

Environment

Product	Version
Pivotal GemFire	All versions