Hi Dennis- I apologize for your troubles. I possibly need to refine the docs; I am open to any suggestions here on how I might make it more clear.
I sense there is possibly some confusion around how multiple annotations work in tandem (e.g. @EnableEntityDefinedRegions with @EnableClusterConfiguration along with using SDG's Function annotation support, enabled with @EnableGemfireFunctions). Without seeing your code/configuration, I am basing my understanding solely on your provided description and the log messages. Let's start with @EnableClusterConfiguration. 1) First, this annotation only sends *Region* and *Index* (both OQL and *Lucene* Indexes are supported) schema object definitions from the client to the server. Functions are not included in the cluster configuration push from the client. *NOTE: Functions are not supported in the client to server cluster configuration push using @EnableClusterConfiguration since this would require the Function class definition(s) to be on the servers' classpath when the Function(s) get created/registered, which would entail uploading a JAR file. Additionally, Apache Geode does not recognize SDG POJO annotated Function "implementations" [1] (i.e. with @GemfireFunction). See here [2] for more details.* 2) Second, the default behavior of @EnableClusterConfiguration when "pushing" schema object definitions (i.e. only *Regions/Indexes*) from the client to the server is to invoke "internal", "administrative" Functions provided by SDG. E.g. to create *Regions* on the servers from a client SDG uses the o.s.d.g.config.admin.functions.CreateRegionFunction [3]. To create *Indexes* on the servers from a client SDG uses the o.s.d.g.config.admin.functions.CreateIndexFunction [4]. Again, these are "internal" SDG "administrative" Functions and the *default behavior* for @EnableClusterConfiguration when pushing schema object definitions from the client to the server. Additionally, these internal SDG administrative Functions are not automatically registered by SDG on the servers since the servers may not be *Spring* enabled; e.g. they may have been started with *Gfsh* or via some other approach (although, in your case, the servers are *Spring* enabled since you bootstrapped the servers with *Spring Boot*; +1). Furthermore, these SDG provided Functions are not recommended for production purposes either since their "actions" are not recorded by Apache Geode's *Cluster Configuration Service* [5] (yet). Therefore a user must register these Functions manually (although, I am already getting ideas here). For instance, see my SDG integration test for @EnableClusterConfiguration based configuration [6]. Specially, have a look at the "forked" Apache Geode server (*Spring*) configuration here [7] and here [8]. 3) Third, the alternative to using these internal SDG administrative Functions is to set the @EnableClusterConfiguration(*useHttp = true*), By setting the useHttp annotation attribute to *true*, the SDG @EnableClusterConfiguration push will use Apache Geode's *Management* REST API to push the schema object definitions from the client to the servers. This approach has several advantages. One, the internal SDG administrative Functions are not used and therefore are not required to be manually registered on the servers in the cluster. Two, by using HTTP to push configuration from the client to the server, Apache Geode's *Cluster Configuration Service* will record the "actions" sent from the client. Thus, when you add additional members to the cluster, either with Spring Boot, or event with *Gfsh*, they will have the same/consistent configuration. If you shutdown the entire cluster and bring it back up, it will retain the configuration from before; all compliments of Apache *Geode's Cluster Configuration Service*., which SDG uses when useHttp is set to *true*. However, using HTTP does require a full installation of Apache Geode to be present on the system where the server is running. When using *Spring Boot* to bootstrap your servers, you can point these *Spring Boot* configured/bootstrapped servers to a full Apache Geode installation by setting the GEODE_HOME environment variable to the installation directory. FYI, though the Management REST API is not publicly advertised (like the "Developer REST API" [9]), it does exist because 1) I created it when I was working the GemFire/Geode engineering team, and 2) it is the same functionality used by *Gfsh* when you connect via HTTP, like so... gfsh> connect --use-http --url=http://localhost:7070/gemfire/v1 This "Management REST API" was created for the purposes of managing Apache Geode clusters running in a Cloud environment (e.g. AWS, or GCP) so users would not have to worry about firewalls when connecting *Gfsh* locally to the Apache Geode Manager in the cluster running in the Cloud. SDG's @EnableClusterConfiguration uses this vary Management REST API to carry out its function when useHttp is set to *true*. As for your application-defined Apache Geode Functions using SDG's Function annotation support, these will be registered and executable (using SDG's Function execution annotation support [10]) as you would expect. To make all of this more concrete, let me put a quick example together for you showcasing your UC. I will follow up in a short bit once I have completed the example; stay tuned. Cheers, John [1] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-implementation [2] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#_implementation_vs_execution [3] https://docs.spring.io/spring-data/gemfire/docs/current/api/org/springframework/data/gemfire/config/admin/functions/CreateRegionFunction.html [4] https://docs.spring.io/spring-data/gemfire/docs/current/api/org/springframework/data/gemfire/config/admin/functions/CreateIndexFunction.html [5] http://geode.apache.org/docs/guide/12/configuring/cluster_config/gfsh_persist.html [6] https://github.com/spring-projects/spring-data-geode/blob/2.0.2.RELEASE/src/test/java/org/springframework/data/gemfire/config/annotation/EnableClusterConfigurationIntegrationTests.java [7] https://github.com/spring-projects/spring-data-geode/blob/2.0.2.RELEASE/src/test/java/org/springframework/data/gemfire/config/annotation/EnableClusterConfigurationIntegrationTests.java#L195-L197 [8] https://github.com/spring-projects/spring-data-geode/blob/2.0.2.RELEASE/src/test/java/org/springframework/data/gemfire/config/annotation/EnableClusterConfigurationIntegrationTests.java#L207-L220 [9] http://geode.apache.org/docs/guide/12/rest_apps/book_intro.html [10] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-execution On Thu, Dec 14, 2017 at 5:35 PM, Dennis Dai <[email protected]> wrote: > Hello, > > I am running a Geode server instance from spring boot (with > @CacheServerApplication annotation). Then on the client side (also spring > boot applications with @ClientCacheApplication annotation), I am trying to > define some regions (with @Region annotation). Together with > @EnableEntityDefinedRegions and @EnableClusterConfiguration on the client > side and @EnableGemfireFuctions on the server side, I was hoping the > regions would be automatically created on the server. But when I ran the > client app, I am getting an error saying: > > org.apache.geode.cache.client.ServerOperationException: remote server on > 192.168.1.100(SpringBasedCacheClientApplication:50794:loner):55570: > 4310ba57:SpringBasedCacheClientApplication: The function is not > registered for function id CreateRegionFunction > > On the server side, I got a similar error: > > 18:11:40.636 [ServerConnection on port 40405 Thread 1] WARN > org.apache.geode.internal.cache.tier.sockets.BaseCommand - Server > connection from [identity(192.168.1.100(SpringBasedCacheClientApplicat > ion:50794:loner):55570:4310ba57:SpringBasedCacheClientApplication,connection=1; > port=55570]: The function is not registered for function id > CreateRegionFunction > > From @EnableGemfireFunctions API doc: > > Enables GemFire annotated Function implementations. Causes the container > to discover any beans that are annotated with {code}@GemfireFunction{code}, > wrap them in a PojoFunctionWrapper > <https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/function/PojoFunctionWrapper.html>, > and register them with the cache. > > I thought that is all I need to get the spring data geode’s functions > (e.g., CreateRegionFunction) registered on the server side. What am I > missing here? > > Thanks, > Dennis > -- -John john.blum10101 (skype)
