|Pivotal GemFire||All versions|
This article describes some pitfalls and recommendations when coding listeners.
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
CLASSPATH variables are already defined as environment variables.
To solve this, make sure your
Declarable if you intend to declare the
OperationAsyncEventListener in the
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.