The Pivotal Running Geode Locator Processes documentation states:
"You can run the locator standalone or embedded within another Geode process. Running your locators standalone provides the highest reliability and availability of the locator service as a whole."
Given a cluster with multiple nodes, with a Geode locator and Geode server running on each node...would it make sense to just embed the locator within the Geode server process.
In this scenario, is there any benefit gained by running the locator in a separate process?
You need fewer locators as compared to servers in the Geode system. You could be running say 3 locators and 10s or 100s of servers.
Related
I intend to write integration tests with Cucumber for a GemFire cache client application using Spring Boot and deployed in an Apache Geode client/server topology. I referred to the question - How to start Spring Boot app without depending on Pivotal GemFire cache which was answered in 2018 and also referred to the integration test documentation here - Integration Testing with STDG.
The link to an example concrete client/server Integration Test extending STDG’s ForkingClientServerIntegrationTestsSupprt class appears to be broken.
The purpose of my integration tests would be to:
run an embedded locator and a server during the integration test phase
define the regions for the servers using cluster.xml
create, read, update and delete cache entries and verify the different use cases
Any help regarding the ideal approach to write integration tests (probably using an embedded GemFire locator and server) will be very helpful.
Tried an embedded GemFire CacheServer instance for integration tests using #CacheServerApplication annotation but not sure on how to create ClientCache objects to use the embedded GemFire or whether this is the right way to write the integration tests.
Edit: Also came across this - Is it possible to start a PIvotal GemFire Server, Locator and Client in one JVM? where it is mentioned as - In short, NO, you cannot have a peer Cache instance (with embedded Locator) and a ClientCache instance in the same JVM (or Java application process).
DISCLAIMER: I do not have experience with Apache Cucumber...
However, it is not difficult to spin up multiple GemFire or Geode server-side processes, such as 1 or more Locator and [multiple] CacheServers in a single test class. The Locators can be standalone JVM processes or embedded, as part of the servers.
In this typical test configuration arrangement the GemFire or Geode server-side processes are forked, yet coordinated, and the test class itself acts as the ClientCache instance.
You can see 1 such test configuration in the SBDG Multi-site Caching sample, here.
The key to this test configuration is the extension of the ForkingClientServerIntegrationTests class from STDG, as well as the forking of the 2 clusters (and specifically), in the test class setup method.
The configuration for each cluster is handled by Spring config and the coordination is all handled using GemFire/Geode properties (specifically) combined with some Spring Profiles (for example, then see here) to control which configuration gets applied for each GemFire/Geode JVM process.
Of course, this example and test configuration is quite complex given the fact that the test also employs GemFire/Geode's WAN capabilities, hence the "multi-site" caching reference, but serves to demonstrate that Spring and SBDG/SDG/STDG supports as complex or as simple of a setup as your testing needs require.
You can start any number of GemFire/Geode processes (Locators, CacheServers, etc). And, in nearly all cases, the test class (JVM) itself is the cache client (ClientCache instance).
Here are a couple more examples from the Spring Data for Apache Geode (SDG) codebase and test suite: here and here.
I am certain I have another test class or example (somewhere) that for a single Locator, then joined 2 CacheServer instances, and then the test (JVM process) proceeded as ClientCache instance, but I cannot seem to find it at the moment.
In any case, I hope this gives you some ideas.
I tried to create a cluster in Apache Geode by providing the hostname and ip address of the remote system in the gemfire.properties file. Somehow, I am not able to create a cluster.
Can anybody please help with steps to create a cluster (including multi-site).
Thank you
It's not clear from the description if you just want to create a simple GemFire cluster or multiple clusters connected through the Geode WAN replication mechanism...
That said, to start a local Geode cluster you can go trough Apache Geode in 15 Minutes or Less, it's a quick introduction that shows you how to use gfsh to start a locator and some servers, create a region, monitor the system using PULSE, etc.
To setup WAN replication, on the other hand, you can go through Configuring a Multi-site (WAN) System, the most important thing to note about this configuration is that your locators need to know about the locators on the remote system, so you need to make sure that the property remote-locators is correctly configured. Once the locators can talk to each other over the WAN, they will share the connection information with the local servers and these, in turn, will be able to communicate with the servers on the remote clusters.
Hope this helps.
Cheers.
We are using apache ignite as a IMDG in our micro services environment.
For scalability and load balancing we are considering to use a service registry like eureka or consul which is supported by spring cloud for the deployed micro services.
There is a concept of service grid providing support for node singleton and cluster singleton in apache ignite.
I also see WCF,weblogic and JBoss to having the same sort of features.
I am trying to understand what these service grids are and if i can use them to achieve the same benefits as the eureka service registry provided by netflix and supported by spring cloud.
Can someone guide if i can achieve the same using service grid in apache ignite.
No, you cannot use Apache Ignite Service Grid for the same purposes as Eureka. Eureka is used for load balancing and service discovery over WAN. Using Ignite clusters spanning over multiple AWS zones and remote client machines is not the most efficient way of using it.
More information on Ignite Service Grid can be found here - http://apacheignite.gridgain.org/docs/service-grid
Thanks!
UPD (for the 1st comment):
You cannot (in most cases) span and effectively use Ignite over WAN networks with high latencies and lower throughput characteristics.
As far as local clusters in non-cloud environments - go ahead! This is the best environment for systems of such kind.
We have a problem with ignite when we start two ignite server nodes at the exact same time. We are currently implementing our own discovery mechanism by extending TcpDiscoveryIpFinderAdapter. The first time the TcpDiscoveryIpFinderAdapter is called neither ignite servers will be able to find the other node (due to the nature of our discovery mechanism). Subsequent invocations does report the other node with a correct IP, yet the ignite nodes will not start to talk to each other.
If we start the servers with some delay, the second server will (on the first attempt) find the other node and join the cluster successfully.
Is there a way to get the two nodes to talk to each other even after both of them initially think they are a cluster of one node?
HI, just now i download the Elastic Load Balance 2.1.0 from WSO2 ,It
is running on terminal side of Linux ubuntu, but it is not showing the
Management console url. If it is not showing url where can i get UI
of Elastic Load Balance.
i have a multiple esb server with same configuration.if my a1 server
go down that time data load will shift to my a2 server .Is this use of
Elasticloadbalance will you explain me about this what is the exactly
use of this .
No, there is no UI component for ELB. Everything has to be done through configuring physical files.
Elastic LoadBalancer 2.1.0 is based on Hazlecast dependent clustering. This has two parts, one is load balancing and the other is elasticity. Load Balancing is simply distributing workload among a number of endpoints configured in a static or dynamic manner. Elasticity is simply scaling, ie monitoring load on worker nodes and starts or terminates nodes based on need on an IaaS environment.
Not only manages when a node goes down but also depending on load it can spawn new nodes to handle and if the load is low it can kill unwanted instances in an IaaS environment.