Apache Geode deploys jars to members

      You can dynamically deploy your application jar file to specified members or all members of the distributed system. Geode automatically tracks the version of the jar file; automatically loads the deployed jar file to the classpath; and automatically registers all functions contained in the jar file.

 

      To deploy or uninstall jar files in Apache Geode, use the gfsh deploy or uninstall command. You can deploy a single jar or multiple jars (by specifying the jar filename or specifying a directory containing the jar file), and you can also target the deployment to a member group or multiple member groups. For example, after connecting to the distributed system where you want to deploy the jar file, you can type the following command at the gfsh prompt:

    

gfsh> deploy --jar=group1_functions.jar

     this commandgroup1_functions.jar文件布署到了分布式系统中的所有成员中，为了部署jar文件到部份

 

成员, use the --group parameter, for example:

  

gfsh> deploy --jar=group1_functions.jar --group=MemberGroup1

 In this example, it is assumed that you have defined the member groups you want to use at startup

. See Configuring and Running a Cluster for more information on how to define member groups and add members to a group. 

 

Deploy all jar files in the specified directory to all members:

 

gfsh> deploy --dir=libs/group1-libs

When deploying you can provide either the jar file name or the directory of the jar file, but you cannot specify both at once.

 

 

Uninstall all previously deployed jar files in the distributed system:

 

gfsh> undeploy

Uninstall the specified jar file:

 

 

gfsh> undeploy --jar=group1_functions.jar

Uninstall all jar files targeting the specified member group:

 

 

gfsh> undeploy --group=MemberGroup1

Only all jar files previously deployed in the member group MemberGroup1 will be uninstalled.

 

View all jar files deployed in your distributed system:

 

gfsh> list deployed

View all jar files deployed in the specified group:

 

 

gfsh> list deployed --group=MemberGroup1

Sample output:

 

 

Member   |     Deployed JAR     |                JAR Location            
--------- | -------------------- | ---------------------------------------------------
datanode1 | group1_functions.jar | /usr/local/gemfire/deploy/vf.gf#group1_functions.jar#1
datanode2 | group1_functions.jar | /usr/local/gemfire/deploy/vf.gf#group1_functions.jar#1

 For more information on using gfsh, see gfsh (Geode SHell) .

 

JAR file deployment location

The system location where the jar file is written on each member depends on the deploy-working-dirproperties Geode configures for each member. For example, you can gemfire.properties文件中use the following configuration in your members:

 

#gemfire.properties
deploy-working-dir=/usr/local/gemfire/deploy

 This deployment location can be local or a network resource (such as a mounted location) shared among multiple members to save disk space. If you use a shared directory, you still need to deploy the jar files you want to access in your application on each member, because deployment updates the classpath and automatically registers functions.

 

About jar file deployment and cluster configuration services

       By default, the cluster configuration service distributes deployed jar files to all locators in the distributed system. When you start a new server with gfsh, the locator provides configuration files and deploys jar files to members and writes them to the server's directory. View the Cluster Configuration Service Overview

 

JAR file versioning

       When you deploy a jar file to a distributed system or member group, the jar file is modified to display version information in the filename. Each jar filename is prefixed with vf.gf# and includes a version number at the end of the filename. For example, if you deploy MyClasses.jar五次，当你列出所有部署的jar包时文件名显示为 vf.gf#MyClasses.jar#5。       when you deploy a jar file, the member receiving the deployment checks to see if the jar file is duplicated, either because it has already been deployed in this member, or because the jar file is already in a shared deployment that is also used by other members content. If other members have already deployed the jar file to the shared directory (using byte alignment to compare with the latest version in its directory), the member receiving the latest deployment will not write the file to disk. Instead, members update the classpath loader to use the deployed jar file. If a newer version of the jar file is detected on disk and is already in use, the deployment will be canceled. When a member starts using a jar file, the member acquires a shared lock on the file. If the member receives a newer version of the file through the deployment, the member releases the share and tries to delete the existing jar file and replace it with the new version. If no other member holds a shared lock on the existing jar file, then the existing, old version of the jar file will be deleted.

Automatic classpath loading

     When a cache is started, the new cache requests the latest version of each jar file to be added to the classpath loader in the current working directory. If a jar file has been deployed to the classpath loader, the classpath loader will update its loaded version if a new version is found; otherwise, there will be no changes. If it is detected that no other members hold shared locks on older jar files, those files will be deleted.

 

      Unloading a jar file does not automatically unload classes already loaded in the deployment. You need to restart your members to unload these classes.

    

      When a cache is closed it requests that all currently deployed jar files be removed from the classpath loader.

 

      When you use a shared deployment working directory, all members sharing this directory should belong to the same member group. All members sharing this directory will deploy and autoload their classpath and all jars found in the current working directory before starting. This means that some members may load these jars even if they are not part of a previous deployment that the member group received.

 

Automatic function registration

 

       When you deploy a jar that contains a function (in other words, a class that implements the functional interface) the function is automatically passedFunctionService.registerFunction方法注册。如果另外一个有相同函数的jar文件被部署（有相同的jar文件名或是别的文件名），这个新的函数的实现会被注册，覆盖掉旧的。如果一个jar文件被卸载，任何在部署时注册的函数将会被取消注册。每次当多次部署一个相同名字的jar文件会倒致正在卸载或是重复部署的的jar文件，

of them函数被取消注册并再次注册。如果一个有相同的ID函数从不同名称的jar包中被注册，那么重复部署的或是已卸载的jar包中的函数将被取消注册。

 

        During cache.xml loading, any declared parameters are preserved. If found in the jar file函数也是被声明过的，并且与在加载cache.xml时声明的参数有相同的类名，那么函数实例将使用参数被创建并被注册。因此，如果相当的函数在cache.xml中用不同的参数集合被声明多次

当jar被部署时，一个函数会为每个参数集合被实例化。如果任何函数被注册时使用来自加载cache.xml时的参数，默认的，没有参数的函数不会被注册。