Take this scenario as an example.
1) start server
2) Cache initializes and starts cacheserver
3) run custom code to build up meta structures for custom implementation
In this scenario, the cache has initialized and the cacheserver has been
started. So clients can start interacting with the server whilst it is
trying to build up custom add meta structures. Which may mean that the
client could receive incorrect results for queries or incorrect behavior
due to the data structures being "not ready"
If the capability is introduced to manually start the cacheserver then
this could go away.
1) start server
2) Cache initializes
3) run custom code to build up meta structures for custom implementation
4) start cacheserver
I agree, adding this flag because it did not correctly initialize the
cache/region/data structures that is crazy. If there is an issue where a
server has started up and is still waiting to GII messages, that should
be addressed as a bug.
--Udo
On 1/5/17 12:55, Kirk Lund wrote:
So here's the what's going on: a User is starting Servers using "start
server" and apparently Clients are able to connect and perform operations
*before* the Cache has completed initialization. So now, I'm being asked to
change "start server" into a 2-command process (as an option):
1) gfsh> start server --name=Server1 --disable-default-server
2) User waits until the Cache initialization is completed
3) gfsh> start client-server-acceptor --name=Server1
I think this is crazy. If this is a problem then Geode Client/Server has a
bigger problem and this requires a fix in Cache initialization, NOT by
adding a new GFSH command.
The launcher class used by GFSH is ServerLauncher, not the older deprecated
CacheServerLauncher. But what you're stating is still correct:
ServerLauncher starts the Client/Server acceptor AFTER the DS is connected
and Cache is created.
So I'm trying to understand why we're trying to solve this in GFSH instead
of in the Server code.
-Kirk
On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith <dsm...@pivotal.io> wrote:
How are you starting up your system? If you initialize a system with a
cache.xml or cluster configuration, the cache server and gateway acceptors
are started last (see CacheCreation.create). If your cache server is
started using gfsh start server, I believe the acceptor part is also
started last (see CacheServerLauncher.createCache).
If you are using the API, it's up to you to start the cache server last. I
don't think there is any latch we can add in that case unless we also added
a method to indicate that you are done configuring the system.
-Dan
On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz <mst...@pivotal.io> wrote:
To be honest I always just thought it was there. I bet most users do.
This
might explain some "unexplained" inconsistencies I have seen at a
customer.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund <kl...@apache.org> wrote:
So, I'm looking into an issue in which the Geode Server starts up and
accepts connections from Clients and starts handling their requests
before
its Cache has completed initialization.
Regions have a series of initialization latches that local puts and
gets
are forced to wait on. For example, initializationLatchAfterGetIni
tialImage
is released after GII completes for that Region. Local puts and gets
are
not allowed to be handled until after GII completes.
I would expect the Cache to have an initialization latch as well that
Client requests have to wait on before the Geode Server completes Cache
initialization.
Does anyone know why Cache or AcceptorImpl don't have an initialization
latch like this? Does anyone have a good reason to not add such an
initialization latch to protect incoming Client requests?
Thanks,
Kirk
