{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 劫难 的问题《Spring Data GemFire and loose coupling between Gem》','https://www.manongdao.com/q-1016493.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
We have a GemFire cluster with 2 Locators and 2 Cache nodes.
Our Spring Boot services will connect to the GemFire cluster as clients and will have client Regions. We are using Spring Data GemFire to bootstrap client Regions with GemFire XML config and properties.
When the GemFire cluster is down the Spring Boot service is not coming up as it couldn’t satisfy the GemFire Region dependencies (UnsatisfiedDependecyException) .
Is there a way to loosely couple Spring Boot startup and GemFire?
In essence, we want the Spring Boot service to start even when the GemFire cluster is down.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="http://www.springframework.org/schema/gemfire"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd">
<util:properties id="gemfireProperties" location="classpath:gemfire.properties"/>
<bean id="autoSerializer" class="org.apache.geode.pdx.ReflectionBasedAutoSerializer">
</bean>
<gfe:client-cache pdx-serializer-ref="autoSerializer" pdx-read-serialized="true" pool-name="POOL" properties-ref="gemfireProperties"/>
<gfe:pool id="POOL" subscription-enabled="true" >
<gfe:locator host="${gf.cache.locator1}" port="${gf.cache.locator1.port}"/>
<gfe:locator host="${gf.cache.locator2}" port="${gf.cache.locator2.port}"/>
</gfe:pool>
<gfe:client-region id="xyz" shortcut="CACHING_PROXY" pool-name="POOL">
<gfe:regex-interest pattern=".*" result-policy="KEYS_VALUES"/>
</gfe:client-region>
</beans>
@ImportResource({"classpath:gemfire-config.xml"})
What you are asking is possible to do, but not without some custom code.
And, it would be much easier to accomplish using Java-based, Spring Container Configuration along with SDG's API than using either Spring (Data GemFire) XML config or (Did I read this right?? You are (possibly) using...) GemFire XML config.
First, though, I wonder in what capacity are you using Pivotal GemFire that your Spring Boot applications (or services) do not strictly require GemFire to be running (server-side) to function properly and so that your Spring Boot apps/services will still startup and service your customers' needs?
Clearly, Pivotal GemFire is not being used as a System of Record (SOR) for your Spring Boot services in this case. However, it would make sense if you were simply using Pivotal GemFire for "caching", perhaps as a caching provider (or this) in Spring's Cache Abstraction? Is this what you are doing?
Anyway...
I think the best way to demonstrate this is by example with an Integration Test, ;-)
I wrote a simple Integration Test,
ResilientClientServerIntegrationTests, where the test is functioning as an application (toput/getdata to/from aRegion, i.e. "Example") and demonstrates that it can "conditionally" switch between client/server and local-only mode.The key to the test (or Spring-based application) to switch between client/server and local-only mode is by implementing a custom Spring Condition and then using the
@ConditionalSpring annotation on the application (client) configuration class, as shown here.However, instead of completely disabling the GemFire client when the server cluster is not available, I simply switch the application (a.k.a. test) to run in client, local-only mode.
I specifically do this by configuring the client Regions to use the
ClientRegionShortcut.LOCALsetting. I then use this setting in the configuration of my client-side GemFire objects, e.g. on the "Example" client Region, see here, then here.Now, if I run this test, it will pass whether or not I have a GemFire cluster (of servers) running, because if there is no GemFire cluster available, then it will simply function in local-only mode.
If a GemFire cluster has been made available to the application, then it will also work as expected and use the cluster without changing any client application code or configuration, neat huh!
So, by way of example, suppose I start a cluster using Gfsh, like so...
Now, I run the test again, it passes, and then I assess the state of the cluster:
Cool! It worked! Our "Example" Region contains an entry put their by our test/application.
If I stop the cluster and re-run the test, of course, it will still pass because the code/configuration smartly switches back to local-only mode, seamlessly without doing anything.
If you are unclear/uncertain that the test is doing what I say it is doing, then simply comment out the @Conditional annotation that is responsible for A) determining whether the GemFire cluster is available and B) deciding how to handle the situation when the cluster is unavailable, which in this case we simply switch to local-only mode.
But, by commenting out that condition, you would see an Exception similar to the following:
That is
NoAvailableLocatorsException, because the "default" isPROXY(again, here) which expects that a cluster with the corresponding client Region (i.e. "Example") exists in the server cluster.Of course, you can completely disable any GemFire client configuration in your [Spring [Boot]] application/services if you absolutely and strictly don't want any GemFire client objects functional when the cluster is not available. You would simply return false here. You just have to be careful that your application has not auto-wired any GemFire objects in this case, for example.
Also, you can accomplish a similar effect with Spring XML config as well, but using Java-based Spring configuration was much easier to demonstrate and I leave it as an exercise for you to figure out.
Additionally, the logic to test the availability of the cluster, while effective (and hardcoded, :P), is crude and I leave it to you to add more "robust" logic.
But, I trust this addresses your question adequately.
Hope this helps!
Cheers!