Before you implement an AsynchEventListener, be aware of the
requirements and guidelines.
- All AsyncEventListener
implementations should check for the possibility that an existing database
connection may have been closed due to an earlier exception. For example, check
Connection.isClosed() in a catch block and re-create
the connection as needed before performing further operations. The
DBSynchronizer implementation in GemFire XD automatically performs this type of
check before reusing a connection.
- An AsyncEventListener implementation must be
installed on one or more members of the GemFire XD system. You can install
AsyncEventListeners only on data stores (peers configured with the property
host-data set to " true").
- You can install a listener
on more than one member to provide high availability and guarantee delivery for
events, in the event that a GemFire XD member with an active AsyncEventListener
shuts down. At any given time only one member has an active thread for
dispatching events. The threads on other members remain on standby for
- Install no more than one
standby listener (redundancy of at most one) for performance and memory
- To preserve pending events
through member shutdowns, configure GemFire XD to persist the internal queue of an
AsyncEventListener to an available
store. By default, any pending events that reside in the internal queue
of an AsyncEventListener are lost if the active listener's GemFire XD member shuts
- To ensure high availability
and reliable delivery of events, configure the event queue to be both
persistent and redundant.
- If your listener implementation must deliver user credentials to an outside data source,
consider encrypting the credentials using encrypt-password with the external option. You
can then supply the encrypted password (rather than a clear-text password) to your
listener via initialization parameters. The listener can then use the
AsyncEventHelper.decryptPassword method to decrypt the password
before in order to connect to the outside data source.