Wow, thanks a lot for the detailed explanations and references! I was slowly 
going through the documentation and trying out different things. FYI, I did hit 
the bug you reported in DATAGEODE-68 along the way and resolved it with your 
suggestions. I also discovered a few minor typos in the documentation, where 
should I report those?

Thanks,
Dennis

> On Dec 15, 2017, at 12:07 PM, John Blum <[email protected]> wrote:
> 
> 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 
> <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
>  
> <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
>  
> <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
>  
> <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
>  
> <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
>  
> <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
>  
> <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
>  
> <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
>  
> <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 
> <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
>  
> <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] 
> <mailto:[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(SpringBasedCacheClientApplication: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)

Reply via email to