部署一个JARS应用到Pivotal Gemfire成员中

部署一个JARS应用到Pivotal Gemfire成员中：

可以动态的在分布式系统中指定成员或者全部成员上部署一个JAR文件应用，Gemfire自动跟踪JAR文件的版本，自动加载部署的JAR文件到CLASSPATH，自动这侧JAR文件包含的所有方法。

在Pivotal Gemfire中部署和卸载一个JAR文件应用，用gfsh命令工具中的deploy和undeploy命令进行操作，你可以部署一个简单的JAR文件应用，也可以部署一个含义多个JAR文件的应用（指定JAR文件的文件名或者指定包含JAR文件的目录）。你也可以将一个成员组或者多个成员做作为部署目标。例如：当你链接到你想部署JARS文件应用的分布式系统之后，可以在gfsh中提示类型。

gfsh> deploy --jar=group1_functions.jar

这条命令是将JAR文件应用部署到所有的分布式系统成员上，想要将JAR文件应用部署到成员的子集中，可以用下面这条命令：

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

在这个例子中，当启动成员的时候，假定你已经定义了你想要使用的成员组，可以看136中使用成员组，这里包含很多信息（怎样建立一个成员组，或者在一个组中添加一个成员）

在所有的成员中部署在本地指定目录下的所有JAR文件

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

既可以提供一个JAR文件的文件名，也可以提供需要部署的包含JAR文件的目录。但是不可以一次指定两个。

卸载所有先前部署在分布式系统上的JAR文件应用

gfsh> undeploy

卸载一个特定的JAR文件

gfsh> undeploy--jar=group1_functions.jar

卸载一个特定成员组上的所有JAR文件

gfsh> undeploy --group=MemberGroup1

只有先前被加载到MemberGroup1组中成员的JAR文件被卸载。

 

查看在分布式系统中部署的所有JAR文件

gfsh> list deployed

查看在分布式系统特定成员组中部署的所有JAR文件

gfsh> list deploy --group=MemberGroup1

简单的输出：

 

 

查看更多gfsh命令的使用信息可以查看第143页，Using the Pivotal GemFire SHell (gfsh)

 

JAR文件的部署位置

JAR文件的系统位置被写在每一个成员的Gemfire性能配置文件中，被配置文件中的deployworking-dir决定。可以通过下面的命令对每个成员的配置文件gemfire.properties进行配置。

 

    部署的位置可以放在本地磁盘，有时候为了减少磁盘空间的也会部署在多中成员使用的共享资源上，如果你使用了一个共享的目录，你如果想要利用这个应用，你仍然需要将这个JAR文件部署到每个成员上。因为部署重新更新了CLASSPATH以及注册了方法。

 

关于部署JAR文件和集群配置服务

默认情况下，集群配置服务将所以已部署的JAR文件分配到分布式系统的所有locators中。当你想要使用gfsh命令启动server时，locator提供配置文件和已部署的JAR文件到所有的成员中，并将它们写到sever的目录下。

 

JAR文件的版本控制

当你部署一个文件到分布式系统或者成员组的时候，这个JAR文件的名字被修改，从而指定它的版本信息。每一个文件的前缀包括vf.gf#，在文件名的后面包含一个版本号。例如：当你将MYClass.jar文件部署五次的时候，这个文件的名字将会改成vf.gf#MyClasses.jar#5。

 

当你部署一个新的JAR文件的时候，成员会接受检查部署的JAR文件是否是重复的，要么是因为这个JAR文件已经部署在了那个成员中，要么是因为这个JAR文件已经被部署到了一个其他成员使用的共享部署工作目录。如果其他的成员已经将这个JAR文件部署到了共享的目录（决定通过byte-for-byte比较到最新版本的目录），成员接受最新的部署但是不将这个文件写入磁盘。相反，这个成员使用已经安装的JAR文件来更新ClassPathLoader。如果在磁盘上检测到了一个新的JAR版本，并且已经在使用了，这个部署将要被取消。当一个成员开始使用一个JAR文件，这个成员会获得一个共享锁文件，如果这个成员通过部署获得了一个新版本的JAR文件，这个成员将会释放这个共享文件锁，为了支持新版本的JAR文件，将试图删除这个已经存在的JAR文件，如果没有其他的成员在这个已经存在的JAR文件上有共享锁，这个存在的JAR文件将会被直接删除。

 

自动加载类路径

当启动一个cache的时候，这个新的cache需要将现有工作目录下的最新版本的JAR文件，添加到ClassPathLoader。如果一个JAR文件已经部署到了ClassPathLoader中，如果一个新的版本被发现，那么这个ClassPathLoader将会更新它的加载的版本。负责，就不会发生改变。如果检测到新版本，如果没有其他成员在这个版本的JAR文件上存在共享锁，那么老的版本的JAR文件将会被删除。

取消部署JAR文件并不会自动卸载在部署期间加载的类。你需要重新启动成员去卸载这些类。

当一个cache被关闭的时候，它需要将所有当前部署的JAR文件从ClassPathLoader中删除。

如果你使用一个共享的空间目录，所有成员使用的共享目录都应该属于同样的成员组，一经重启，共享相同部署工作目录的所有成员将会通过在共享空间目录发现的JAR文件来部署和自动加载它们的CLSSPATH。这也意味着有些成员可能加载JAR文件（即使他们不属于已经接受原来部署的成员组）。

 

自动注册功能

当你注册一个包含功能（换句话说：就是包含实现一个功能接口的类）的JAR文件的时候，这个功能通过FunctionService.registerFunction方法自动注册，如果另一个含有相同功能（要么JAR文件名字相同，要么不同）的JAR文件被部署，这个功能的最新实现将会被注册，并且覆盖原来的那个。如果一个JAR文件被取消部署，那么在部署JAR文件期间自动注册的功能将被取消注册。因为部署的JAR文件存在相同的名字多次导致JAR被取消部署和重新部署，JAR文件中的功能都没有被注册，或者每次重新注册的时候都会发生这种情况。

在cache.xml加载期间，这些可以申报的参数被保存，如果在JAR文件中发现的功能也是可申报的，有相同的类名（加载cache.xml之后，参数被保存）作为可申报的，接着功能的例子可以通过这些参数被创建和被注册，因此，如果相同的功能在在cache.xml中通过不同组的参数多次声明，当部署的JAR文件为每个设置参数的功能实例化，如果任何一个功能的参数从cache.xml中加载，默认情况下，无参函数是不能被注册的。