Hi Jayesh- Last response to your last email. Regarding...
*> I am looking for how I can register/create new regions by deploying jar to server without restarting it. GFSH create region is surely a way but anything possible using spring data geode or native cache xml using gfsh deploy? * Again, if you are looking to (re-)configure your Geode Servers based on current application changes (i.e. a new version) by using *Spring* configuration meta-data, expecting to include the *Spring* config files in a JAR file (containing either XML or @Configuration annotated Java classes) that you can then push to the cluster using *Gfsh's* `deploy` command without restarting your *Spring*-configured Geode Servers, then NO, this will not work. *Gfsh's* `deploy` command does not support "configuration changes", whether that includes *Spring* config, or even Geode's native config (e.g. cache.xml) for that matter. AFAIK, presently, *Gfsh's* `deploy` command only recognizes *Functions*, nothing else. Even if Geode recognized new *Spring* configuration, it would require the *Spring* container to be "refreshed" [1] inside the *Spring*/Geode JVM process. Note, "refreshing" the *Spring* container should not be confused with a complete JVM restart. Effectively, the "refresh" involves recreating/initializing the beans managed by the *Spring* container from (perhaps) updated/new bean definitions declared in the configuration meta-data. Although... you could conceive of a Geode Function where it would acquire a handle to the *Spring* container (ApplicationContext), apply the updated configuration updates and then call ConfigurableApplicationContext.refresh(). You could upload a JAR containing the "Update" Function along with the *Spring* config to make this happen. This is not supported OOTB but is possible, I suppose; I leave that as an exercise for you to try. *> As I explained, what's the recommendation to deploy/release new version of spring boot jar to production? Is is like i have to always restart server?* Yes. A restart is required when updating any Geode Server dependency (e.g. Log4j), not just *Spring Boot*, *Spring Data Geode*, or *Spring* in general So there it is, I hope this helps! Regards, John On Wed, Sep 6, 2017 at 2:16 PM, John Blum <[email protected]> wrote: > Hi Jayesh- > > Continuing on with your second question... > > *> 2. Assuming that my first deployment of project was POC-1.0.0.jar > release, how I should organize code for next release with only few new > regions?* > > Well, depends on whether you prefer to use *Spring* config or not. > > If you prefer *Spring* config (XML/Java) then you will need to bounce > your servers no matter what. Otherwise, if you prefer not to, or are unable > to, restart your servers, then you must use *Gfsh* to configure new > Regions. > > Geode's *Cluster Configuration* service handles the organization of the > configuration (artifacts) for you. CC will also handle applying the > configuration to any newly added servers, *Spring*-based or otherwise, > providing you enable the use of Cluster Configuration service for Geode > Servers configured with Spring as I explained previously. The whole point > of using *Gfsh* is not to worry about the "configuration artifacts" and > where they are maintained. > > So, you do not need to worry about this... > > *> I found that we can deploy some jars to server using gfsh deploy, but i > am not sure about folder structure it should follow.* > > You should not muck working directory folder structure setup by Geode when > the server/node starts. You should retain this working directory as is > from which you launched your server (*Spring Boot*, *Gfsh*, or otherwise) > since it will contain the config files and other artifacts (e.g. deployed > JARs, possibly *DiskStore* files depending on your configuration, etc). > Inside your JAR file, the organization does not matter; i.e. follow normal > Java JAR semantics. > > This... > > *> **Also if that would also be spring boot project with <gfe:region..> > tags only without Spring Boot Main?* > > ... does not apply to new Regions; you must add new Regions to existing, > running servers via *Gfsh*. > > > -John > > > On Wed, Sep 6, 2017 at 2:00 PM, John Blum <[email protected]> wrote: > >> Hi Jayesh- >> >> Sorry for the delayed response; I was on VAC for the past couple weeks. >> >> I would also suggest if you have critical questions involving both >> *Spring* with Apache Geode or Pivotal GemFire, that *StackOverflow* [1] >> is a much better forum than Apache's antiquated mailing lists. I prefer to >> only respond on SO, particularly where *Spring* is involved. There is a >> tag for spring-data-geode [2] but users tend to only use the >> spring-data-gemfire tag [3] (along with geode tag [4]) for Geode related >> questions, FYI. >> >> >> Regarding your questions (in order)... >> >> >> *> 1. How can I create a new region in group "GROUP1" with domain class >> definition without restarting my servers now?* >> >> First, it starts by configuring your Geode servers (*Spring Boot*-based >> or otherwise) to start in a particular group using the Geode "groups" >> property [5]. Based on your replies, it sounds like you have done this. >> >> Then, as *Anil* pointed out, when creating a Region via *Gfsh*, you can >> specify the "group(s)" of the servers in which the new Region should be >> created... >> >> >> gfsh>help create region >> NAME >> create region >> IS AVAILABLE >> true >> SYNOPSIS >> Create a region with the given path and configuration. Specifying a >> --key-constraint and --value-constraint makes object type information >> available during querying and indexing. >> PARAMETERS >> ... >> * group* >> * Group(s) of members on which the region will be created.* >> * Required: false* >> >> >> So, let's use an example. As I pointed out in another thread [6] >> recently, I have a *Spring Boot GemFire/Geode Server* example [7] that >> configures and bootstraps a Geode Server in a *Spring Boot*, JVM-based >> application process. >> >> I am modifying this example slightly so that... >> >> 1. I can start the Locator with *Gfsh* and have my >> SpringBootGemFireServer application connect to the *Gfsh *launched Locator >> instead. >> >> gemfireProperties.setProperty("locators", locators); >> >> If you run the example yourself, be mindful of the embedded services >> (i.e. Locator, Manager, CacheServer) started/enabled by the >> SpringBootGemFireServer class, especially when starting multiple Geode >> processes, otherwise you will run into conflicts, such as >> java.net.BindExceptions when ports are already in use (especially, the >> default ports). >> >> 2. I configure my SpringBootGemFireServer to be in the "*Spring*" group >> using the Geode "group" property. >> >> gemfireProperties.setProperty("group", "Spring"); >> >> 3. Finally, I am going to enable the use of Geode's *Cluster >> Configuration* service in the SpringBootGemFireServer application, which >> SDG disables by default. >> >> gemfireCache.setUseClusterConfiguration(true); >> >> >> I am starting a Locator via *Gfsh* in order to leverage Geode's *Cluster >> Configuration* service independent of my servers, which is important if >> you want the Region(s) you create, in the desired "group(s)", with >> *Gfsh,* to be "remembered", particularly if the server is ever shutdown >> and brought back online. Since the newly added Region will not be declared >> in either *Spring *XML or Java configuration meta-data you must use *Cluster >> Config*. >> >> Of course, you cannot use *Spring* config to declare a new Region after >> the server is already running without bouncing the server. *Gfsh's* ` >> deploy` command simply does not recognize *Spring* config or any other >> non-Geode artifact. >> >> Despite popular belief (perhaps), *Spring Data Geode/GemFire* *will* >> allow *Cluster Configuration* to be used with/in *Spring* (*Boot*) Geode >> peer cache applications (or rather *Spring*-configured Geode Servers). >> In short, the effect is that any *Spring* config applied on startup will >> "augment" the *Cluster Configuration* (or cache.xml if present) This is >> because Geode/GemFire always applies *Cluster Config* and then cache.xml (in >> that order) before any other configuration meta-data is applied to >> configure the server (outside of Geode properties), including Geode's own >> API too! This is entirely due to the fact that *Cluster Config* and >> cache.xml are applied in the constructor during cache creation (*Cluster >> Config* applied here [8] and here [9]; cache.xml applied here [10]). >> >> This belief is unfortunately present despite the example [11] I created >> sometime ago as well as the documentation I wrote here [12], which has been >> since SDG 1.6 [13] no less! >> >> Alright, let's proceed, shall we... >> >> I start my Locator... >> >> >> $ gfsh >> _________________________ __ >> / _____/ ______/ ______/ /____/ / >> / / __/ /___ /_____ / _____ / >> / /__/ / ____/ _____/ / / / / >> /______/_/ /______/_/ /_/ 1.2.0 >> >> Monitor and Manage Apache Geode >> >> gfsh>start locator --name=*Locator1* --log-level=config >> Starting a Geode Locator in /Users/jblum/pivdev/lab/Locator1... >> ... >> Locator in /Users/jblum/pivdev/lab/Locator1 on 10.99.199.5[10334] as >> Locator1 is currently online. >> Process ID: 26488 >> Uptime: 2 seconds >> Geode Version: 1.2.0 >> Java Version: 1.8.0_121 >> Log File: /Users/jblum/pivdev/lab/Locator1/Locator1.log >> JVM Arguments: -Dgemfire.log-level=config >> -Dgemfire.enable-cluster-configuration=true >> -Dgemfire.load-cluster-configuration-from-dir=false >> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true >> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 >> Class-Path: /Users/jblum/pivdev/apache-geode-1.2.0/lib/geode-core-1.2.0. >> jar:/Users/jblum/pivdev/apache-geode-1.2.0/lib/geode-dependencies.jar >> >> Successfully connected to: JMX Manager [host=10.99.199.5, port=1099] >> >> Cluster configuration service is up and running. >> >> gfsh>list members >> >> Name | Id >> -------- | ------------------------------------------------ >> *Locator1* | 10.99.199.5(Locator1:26488:locator)<ec><v0>:1024 >> >> >> Now, I start my SpringBootGemFireServer class in group "*Spring*" >> connected to Locator1... >> >> >> gfsh>list members >> >> Name | Id >> ----------------------- | ------------------------------ >> --------------------- >> Locator1 | 10.99.199.5(Locator1:26488:loc >> ator)<ec><v0>:1024 >> *SpringBootGemFireServer* | 10.99.199.5(SpringBootGemFireS >> erver:26934)<v5>:1025 >> >> >> gfsh>describe member --name=*SpringBootGemFireServer* >> *Name : SpringBootGemFireServer* >> Id : 10.99.199.5(SpringBootGemFireServer:26934)<v5>:1025 >> Host : 10.99.199.5 >> >> *Regions : Factorials*PID : 26934 >> *Groups : Spring* >> Used Heap : 200M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Log file : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Locators : localhost[10334] >> >> Cache Server Information >> Server Bind : localhost >> Server Port : 40404 >> Running : true >> Client Connections : 0 >> >> >> We can ignore the "*Factorials*" PARTITION Region for this >> demonstration. It comes from the *Spring* Java config here [14]. >> >> Now, let's start another Geode server using *Gfsh* this time, in a group >> called "Geode"... >> >> >> gfsh>start server --name=*Server2* --log-level=config >> --disable-default-server --group=Geode >> Starting a Geode Server in /Users/jblum/pivdev/lab/Server2... >> ... >> Server in /Users/jblum/pivdev/lab/Server2 on 10.99.199.5 as Server2 is >> currently online. >> Process ID: 27021 >> Uptime: 2 seconds >> Geode Version: 1.2.0 >> Java Version: 1.8.0_121 >> Log File: /Users/jblum/pivdev/lab/Server2/Server2.log >> JVM Arguments: -Dgemfire.default.locators=10.99.199.5[10334] >> -Dgemfire.use-cluster-configuration=true -Dgemfire.groups=Geode >> -Dgemfire.start-dev-rest-api=false -Dgemfire.log-level=config >> -XX:OnOutOfMemoryError=kill -KILL %p >> -Dgemfire.launcher.registerSignalHandlers=true >> -Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterva >> l=9223372036854775806 >> Class-Path: /Users/jblum/pivdev/apache-geode-1.2.0/lib/geode-core-1.2.0. >> jar:/Users/jblum/pivdev/apache-geode-1.2.0/lib/geode-dependencies.jar >> >> >> gfsh>list members >> Name | Id >> ----------------------- | ------------------------------ >> --------------------- >> Locator1 | 10.99.199.5(Locator1:26488:loc >> ator)<ec><v0>:1024 >> SpringBootGemFireServer | 10.99.199.5(SpringBootGemFireS >> erver:26934)<v5>:1025 >> *Server2* | 10.99.199.5(Server2:27021)<v6>:1026 >> >> >> gfsh>describe member --name=Server2 >> *Name : Server2* >> Id : 10.99.199.5(Server2:27021)<v6>:1026 >> Host : 10.99.199.5 >> *Regions : * >> PID : 27021 >> *Groups : Geode* >> Used Heap : 15M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/lab/Server2 >> Log file : /Users/jblum/pivdev/lab/Server2/Server2.log >> Locators : 10.99.199.5[10334] >> >> >> Now we have a *Gfsh* started server ("Server2") in group "Geode" with no >> Regions. Onward... >> >> First, let's create a non-group specific Region and see what happens... >> >> gfsh>create region --name=*Example* --type=PARTITION >> Member | Status >> ----------------------- | ------------------------------ >> ------------------------ >> *SpringBootGemFireServer* | Region "/Example" created on >> "SpringBootGemFireServer" >> *Server2* | Region "/Example" created on "Server2" >> >> >> gfsh>list regions >> List of regions >> --------------- >> *Example* >> Factorials >> >> >> gfsh>describe region --name=*Example* >> .......................................................... >> *Name : Example* >> Data Policy : partition >> Hosting Members : *Server2* >> *SpringBootGemFireServer* >> >> Non-Default Attributes Shared By Hosting Members >> >> Type | Name | Value >> ------ | ----------- | --------- >> Region | size | 0 >> | data-policy | PARTITION >> >> >> gfsh>describe member --name=SpringBootGemFireServer >> *Name : SpringBootGemFireServer* >> Id : 10.99.199.5(SpringBootGemFireServer:26934)<v5>:1025 >> Host : 10.99.199.5 >> *Regions* : Factorials >> *Example* >> PID : 26934 >> *Groups : Spring* >> Used Heap : 61M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Log file : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Locators : localhost[10334] >> >> Cache Server Information >> Server Bind : localhost >> Server Port : 40404 >> Running : true >> Client Connections : 0 >> >> gfsh>describe member --name=Server2 >> *Name : Server2* >> Id : 10.99.199.5(Server2:27021)<v6>:1026 >> Host : 10.99.199.5 >> *Regions : Example* >> PID : 27021 >> *Groups : Geode* >> Used Heap : 32M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/lab/Server2 >> Log file : /Users/jblum/pivdev/lab/Server2/Server2.log >> Locators : 10.99.199.5[10334] >> >> >> Next, we can create some "group" specific Regions... >> >> >> gfsh>create region --name=*SpringOnlyRegion* --type=PARTITION >> *--group=Spring* >> Member | Status >> ----------------------- | ------------------------------ >> --------------------------------- >> *SpringBootGemFireServer* | Region "/SpringOnlyRegion" created on >> "SpringBootGemFireServer" >> >> >> gfsh>list regions >> List of regions >> ---------------- >> Example >> Factorials >> *SpringOnlyRegion* >> >> >> gfsh>describe region --name=*SpringOnlyRegion* >> .......................................................... >> *Name : SpringOnlyRegion* >> Data Policy : partition >> *Hosting Members : SpringBootGemFireServer* >> >> Non-Default Attributes Shared By Hosting Members >> >> Type | Name | Value >> ------ | ----------- | --------- >> Region | size | 0 >> | data-policy | PARTITION >> >> >> gfsh>describe member --name=SpringBootGemFireServer >> *Name : SpringBootGemFireServer* >> Id : 10.99.199.5(SpringBootGemFireServer:26934)<v5>:1025 >> Host : 10.99.199.5 >> *Regions* : Factorials >> * SpringOnlyRegion* >> Example >> PID : 26934 >> *Groups : Spring* >> Used Heap : 76M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Log file : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Locators : localhost[10334] >> >> Cache Server Information >> Server Bind : localhost >> Server Port : 40404 >> Running : true >> Client Connections : 0 >> >> >> gfsh>describe member --name=Server2 >> *Name : Server2* >> Id : 10.99.199.5(Server2:27021)<v6>:1026 >> Host : 10.99.199.5 >> *Regions* : Example >> PID : 27021 >> *Groups : Geode* >> Used Heap : 45M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/lab/Server2 >> Log file : /Users/jblum/pivdev/lab/Server2/Server2.log >> Locators : 10.99.199.5[10334] >> >> >> Now for a "Geode" group only Region... >> >> >> gfsh>create region --name=*GeodeOnlyRegion* --type=REPLICATE >> *--group=Geode* >> Member | Status >> ------- | ---------------------------------------------- >> *Server2* | Region "/GeodeOnlyRegion" created on "Server2" >> >> >> gfsh>list regions >> List of regions >> ---------------- >> Example >> Factorials >> *GeodeOnlyRegion* >> SpringOnlyRegion >> >> >> gfsh>describe region --name=GeodeOnlyRegion >> .......................................................... >> *Name : GeodeOnlyRegion* >> Data Policy : replicate >> *Hosting Members : Server2* >> >> Non-Default Attributes Shared By Hosting Members >> >> Type | Name | Value >> ------ | ----------- | --------------- >> Region | data-policy | REPLICATE >> | size | 0 >> | scope | distributed-ack >> >> >> gfsh>describe member --name=Server2 >> *Name : Server2* >> Id : 10.99.199.5(Server2:27021)<v6>:1026 >> Host : 10.99.199.5 >> *Regions* : Example >> >> * GeodeOnlyRegion*PID : 27021 >> *Groups : Geode* >> Used Heap : 50M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/lab/Server2 >> Log file : /Users/jblum/pivdev/lab/Server2/Server2.log >> Locators : 10.99.199.5[10334] >> >> >> gfsh>describe member --name=SpringBootGemFireServer >> *Name : SpringBootGemFireServer* >> Id : 10.99.199.5(SpringBootGemFireServer:26934)<v5>:1025 >> Host : 10.99.199.5 >> *Regions* : Factorials >> SpringOnlyRegion >> Example >> PID : 26934 >> *Groups : Spring* >> Used Heap : 87M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Log file : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Locators : localhost[10334] >> >> Cache Server Information >> Server Bind : localhost >> Server Port : 40404 >> Running : true >> Client Connections : 0 >> >> >> As you can see, Regions will be created on the correct servers when the ' >> --group' option of the `create region` command is specified, or not. >> >> So now, even if I restart the SpringBootGemFireServer, it will retain >> the Regions I created with *Gfsh* since I enabled the "user" of the *Cluster >> Configuration* service, even when configuring the *Spring*-based Geode >> server... >> >> I stop my SpringBootGemFireServer, and now... >> >> >> gfsh>list members >> Name | Id >> -------- | ------------------------------------------------ >> Locator1 | 10.99.199.5(Locator1:26488:locator)<ec><v0>:1024 >> *Server2* | 10.99.199.5(Server2:27021)<v6>:1026 >> >> >> gfsh>list regions >> List of regions >> --------------- >> >> *ExampleGeodeOnlyRegion* >> >> >> No SpringBootGemFireServer present in `list members` and no "*Factorials*" >> or "*SpringOnlyRegion*" Regions present. >> >> Then, I restart the SpringBootGemFireServer, and now... >> >> >> gfsh>list members >> Name | Id >> ----------------------- | ------------------------------ >> --------------------- >> Locator1 | 10.99.199.5(Locator1:26488:loc >> ator)<ec><v0>:1024 >> *SpringBootGemFireServer* | 10.99.199.5(SpringBootGemFireS >> erver:27305)<v8>:1025 >> Server2 | 10.99.199.5(Server2:27021)<v6>:1026 >> >> >> gfsh>list regions >> List of regions >> ---------------- >> Example >> Factorials >> GeodeOnlyRegion >> *SpringOnlyRegion* >> >> >> gfsh>describe member --name=SpringBootGemFireServer >> *Name : SpringBootGemFireServer* >> Id : 10.99.199.5(SpringBootGemFireServer:27305)<v8>:1025 >> Host : 10.99.199.5 >> *Regions* : Factorials >> >> >> * SpringOnlyRegion Example*PID : 27305 >> *Groups : Spring* >> Used Heap : 35M >> Max Heap : 3641M >> Working Dir : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Log file : /Users/jblum/pivdev/spring-data-examples-workspace/spring- >> boot-gemfire-server-example/build >> Locators : localhost[10334] >> >> Cache Server Information >> Server Bind : localhost >> Server Port : 40404 >> Running : true >> Client Connections : 0 >> >> >> Again, or "*Factorials*" and the "*SpringOnlyRegion*" are recreated on >> the SpringBootGemFireServer. Keep in mind that both the "*Example*" and >> "*SpringOnlyRegion*" Regions were created in *Gfsh*, and so do not have >> *Spring* config meta-data. However, the SpringBootGemFireServer still >> contains these Regions when it starts up. How cool is that!! >> >> Even the configuration of my SpringBootGemFireServer shows (when >> log-level is set to "config")... >> >> >> [info 2017/09/06 13:48:24.429 PDT <main> tid=1] >> *************************************************************** >> *Configuration for 'Spring'* >> >> Jar files to deployed >> <?xml version="1.0" encoding="UTF-8" standalone="no"?> >> <cache xmlns="http://geode.apache.org/schema/cache"; xmlns:xsi=" >> http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" >> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" >> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache >> http://geode.apache.org/schema/cache/cache-1.0.xsd";> >> <region name="*SpringOnlyRegion*"> >> <region-attributes data-policy="partition"/> >> </region> >> </cache> >> >> *************************************************************** >> *Configuration for 'cluster'* >> >> Jar files to deployed >> <?xml version="1.0" encoding="UTF-8" standalone="no"?> >> <cache xmlns="http://geode.apache.org/schema/cache"; xmlns:xsi=" >> http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" >> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" >> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache >> http://geode.apache.org/schema/cache/cache-1.0.xsd";> >> <region name="*Example*"> >> <region-attributes data-policy="partition"/> >> </region> >> </cache> >> >> >> Phew! Given the length of this email, I will follow up to you second >> question in a reply. >> >> >> Regards, >> John >> >> >> [1] https://stackoverflow.com/questions/tagged/spring-data-gemfire >> [2] https://stackoverflow.com/questions/tagged/spring-data-geode >> [3] https://stackoverflow.com/questions/tagged/spring-data-gemfire >> [4] https://stackoverflow.com/questions/tagged/geode >> [5] http://geode.apache.org/docs/guide/12/reference/topics/ >> gemfire_properties.html >> [6] http://markmail.org/message/lomcwhh3vw3p24ee >> [7] https://github.com/jxblum/spring-boot-gemfire-server-example >> [8] https://github.com/apache/geode/blob/rel/v1.2.0/geode-co >> re/src/main/java/org/apache/geode/internal/cache/GemFireCach >> eImpl.java#L1148-L1154 >> [9] https://github.com/apache/geode/blob/rel/v1.2.0/geode-co >> re/src/main/java/org/apache/geode/internal/cache/GemFireCach >> eImpl.java#L1193-L1194 >> [10] https://github.com/apache/geode/blob/rel/v1.2.0/geode- >> core/src/main/java/org/apache/geode/internal/cache/GemFireCa >> cheImpl.java#L1195 >> [11] https://github.com/jxblum/spring-gemfire-clusterconfigu >> ration-examples >> [12] https://docs.spring.io/spring-data/geode/docs/2.0.0.RC2 >> /reference/html/#bootstrap:cache:cluster-configuration >> [13] https://jira.spring.io/browse/SGF-226 >> [14] https://github.com/jxblum/spring-boot-gemfire-server- >> example/blob/apache-geode/src/main/java/org/example/SpringBo >> otGemFireServer.java#L116-L129 >> >> >> On Wed, Sep 6, 2017 at 10:36 AM, Jayesh Thacker <[email protected]> >> wrote: >> >>> Thank you for the reply Anil! >>> >>> I already have logical member groups. But I am looking for how I can >>> register/create new regions by deploying jar to server without restarting >>> it. >>> >>> >>> GFSH create region is surely a way but anything possible using spring >>> data geode or native cache xml using gfsh deploy? >>> >>> As I explained, what's the recommendation to deploy/release new version >>> of spring boot jar to production? Is is like i have to always restart >>> server? >>> >>> I don't use any of spring data repository related features but only >>> Spring boot main along with spring beans to register regions/groups based >>> on spring profile + cache servers and actuators. >>> >>> >>> - Jayesh >>> >>> On Wed, Sep 6, 2017 at 1:59 AM, Anilkumar Gingade <[email protected]> >>> wrote: >>> >>>> Jayesh, >>>> >>>> In Geode cluster, you can organize the members/nodes as different >>>> group...And configure/create your regions to be part of specific >>>> group...Gfsh allows you to do that without re-starting the cluster (gfsh >>>> create region has group option). >>>> >>>> Also, you can push your class/jar to the running cluster, using deploy >>>> jar command. >>>> >> POC-1.0.0.jar release >>>> I am assuming you have all the application class files as part of this >>>> jar...There is no specific recommendation on how to manage the application >>>> jars; its up to the app developers to manage their classes... >>>> >>>> I am not that familiar about spring boot; i will let the experts to >>>> chime on this. >>>> >>>> -Anil. >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Sep 5, 2017 at 10:14 AM, Jayesh Thacker <[email protected]> >>>> wrote: >>>> >>>>> Hello folks, >>>>> >>>>> Could some one guide me for this? >>>>> >>>>> Thanks, >>>>> Jayesh >>>>> >>>>> On Wednesday, August 30, 2017, Jayesh Thacker <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi John, >>>>>> >>>>>> I am bit new to apache geode community. I have few questions related >>>>>> to bootstrapping cache server using spring data geode. I could start >>>>>> something running though. >>>>>> >>>>>> Thanks for the geode examples! >>>>>> >>>>>> Currently I have a requirement for 3 DISTRIBUTED regions with pdx >>>>>> serialization organized under 1 logical group called say "group1". >>>>>> >>>>>> I have 2 servers running in my machine with same code base connected >>>>>> to standalone locator started via gfsh. >>>>>> >>>>>> 1. How can I create a new region in group "GROUP1" with domain class >>>>>> definition without restarting my servers now? >>>>>> >>>>>> 2. Assuming that my first deployment of project was POC-1.0.0.jar >>>>>> release, how I should organize code for next release with only few new >>>>>> regions? >>>>>> >>>>>> I found that we can deploy some jars to server using gfsh deploy, but >>>>>> i am not sure about folder structure it should follow. >>>>>> >>>>>> Also if that would also be spring boot project with <gfe:region..> >>>>>> tags only without Spring Boot Main? >>>>>> >>>>>> Thanks, >>>>>> Jayesh >>>>>> >>>>> >>>> >>> >> >> >> -- >> -John >> john.blum10101 (skype) >> > > > > -- > -John > john.blum10101 (skype) > -- -John john.blum10101 (skype)
