Pivotal Knowledge Base


Inconsistent installation of jars using gfxd> CALL sqlj.replace_jar


Product Version
Pivotal GemFire XD All versions


The purpose of this article is to describe an issue where a jar file may be inconsistently installed across the cluster resulting in a situation where the jar file cannot be removed or replaced. Additionally, a workaround to remove the jar file is presented and recommendations for deploying jars on GemFire XD to avoid this issue provided.


When deploying a jar file, during installation or replacement, succeeds on some servers while failing on others, for instance when deploying from NFS, inconsistencies may occur.

In such a case, we will need the full logs, at least from the point of restart, so that we can ascertain where the partial failure occurred.

In this state you can see the following errors:

Jar file 'EVENTLISTENER' does not exist in schema 'TEST'. 
Could not create file TEST.EVENTLISTENER as it already exists. 

Work Around

The attached simple java program will connect to each server and clean up the installed jar. If faced with this situation, please compile it and use it. It does not need any external jar for compilation.

Run Usage:

java -cp .:gemfirexd-client.jar test.JarCleanup  

for example

java -cp .:gemfirexd-client.jar test.JarCleanup jdbc:gemfirexd://localhost:1527/ app.samplejar

After running this tool you can install the new version of the jar.


Do not use a mix of "CALL PROCEDURE" from gfxd shell and gfxd command line utility for replacing jar files. That is, do not do something like:

gfxd> CALL sqlj.replace_jar('/gemfire-lib/event-listener/DBSynchronizerSource.jar', 'ODS.EVENTLISTENER');


gfxd replace-jar -name=ODS.EventListener -user=[username] -password=[password] -file=/gemfire-lib/event-listener/DBSynchronizerSource.jar -client-bind-address=myHostName -client-port=1527 auth-provider=LDAP

The best practice is to use the second option, the command line gfxd, consistently, because it converts the content of the jar file into bytes and sends the bytes for installation to all the servers. By contrast, the first option is dependent on the location of the file on the server, so, if it is not available on the server, there can be inconsistencies in deployment.


Powered by Zendesk