As Jens D comments, you can try the locator-wait-time GemFire (System) property. However, as the documentation points out...
The number of seconds that a member should wait for a locator to start if a locator is not available when attempting to join the distributed system. Use this setting when you are starting locators and peers all at once. This timeout allows peers to wait for the locators to finish starting up before attempting to join the distributed system.
This specifically refers to a "peer member" joining the distributed system/cluster, and thus, may have not any effect from the client (cache).
In which case, I have employed other techniques using Spring (specifically in integration tests involving a client/server topology) to cause the client to block waiting for the Server (or Locator) to become available. In my tests, the test forks a separate GemFire JVM process to run the Server while the test VM serves as the cache client.
You can see examples of this in my most recent development effort by integrating GemFire with Spring Session, specifically, in the httpsession-gemfire-clientserver sample.
Here, I used a BeanPostProcessor that causes the client cache, and specifically the PoolFactoryBean/Pool, to block (in postProcessBeforeInitialization(..)) preventing the Pool from being fully initialized until the Server is available (could also apply to a Locator).
The wait just attempts to open a Socket connection to the Server (or Locator) to verify connectivity.
Another approach is to create a CountDownLatch, use it in a registered GemFire ClientMembershipListener and combine it with, again, the BeanPostProcessor, only in the postProcessAfterInitialization(..) method this time.
Technically, only 1 of the 2 approaches are necessary. While, I used this for testing purposes, this can be used for, and is not uncommon in, an actual application as well.
Ideally, however, you are starting your Locators before anything else, since forming a cluster depends on it.
Hope this helps.
Cheers!
John
