Server accepts clients before its cache is initialized

[Kirk Lund <kl...@apache.org>]

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, initializationLatchAfterGetInitialImage
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

Re: Server accepts clients before its cache is initialized

[Anthony Baker <ab...@pivotal.io>]

-1 for these reasons:

1) If an application needs Cache lifecycle notifications, we should expose that through an event mechanism (register a listener, invoke callbacks).
2) If there is an initialization bug where the CacheServer accepts connections and allows Cache operations prior to completing internal initialization, we should fix that bug.

Anthony


> On Jan 5, 2017, at 12:55 PM, Kirk Lund <kl...@apache.org> 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 <ds...@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 <ms...@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
>>>> 
>>> 
>> 

Re: Server accepts clients before its cache is initialized

[Udo Kohlmeyer <uk...@pivotal.io>]

+1


On 1/5/17 13:58, John Blum wrote:
> In general, I think it would be useful to have a `start/stop/status
> *service*` where services could be any one of [CacheServer,
> GatewayReceiver, RedisService, MemcachedService, HttpService, etc].  As
> user/developer, it would be useful to be able to control the embedded
> services in one or more GemFire/Geode nodes in the cluster.
>
> On Thu, Jan 5, 2017 at 1:57 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
>> +2
>>
>>
>>
>> On 1/5/17 13:53, Kirk Lund wrote:
>>
>>> Ok #3 makes sense then. It's not that the Cache initialization is broken,
>>> it's that some people want to hook in some custom initialization at the
>>> end
>>> of cache creation but before starting the ClientServer component.
>>>
>>> I think it would make the most sense to have Cache initialization
>>> callbacks
>>> (this has been commonly requested by users for as long as I can remember).
>>>
>>> It would also make sense to add lifecycle control commands for starting
>>> and
>>> stopping the ClientServer component (since this isn't a workaround for
>>> some
>>> sinister bug). If we design the start clientserver command correctly then
>>> it's one more step towards completing cluster config in such a way that no
>>> one needs cache.xml anymore. Right now if a user wants to create multiple
>>> ClientServer endpoints then they have to use cache.xml in addition to
>>> starting the default-server with the start server command.
>>>
>>>
>>> On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <uk...@pivotal.io>
>>> wrote:
>>>
>>> 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 <ds...@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 <ms...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>

Re: Server accepts clients before its cache is initialized

[John Blum <jb...@pivotal.io>]

In general, I think it would be useful to have a `start/stop/status
*service*` where services could be any one of [CacheServer,
GatewayReceiver, RedisService, MemcachedService, HttpService, etc].  As
user/developer, it would be useful to be able to control the embedded
services in one or more GemFire/Geode nodes in the cluster.

On Thu, Jan 5, 2017 at 1:57 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:

> +2
>
>
>
> On 1/5/17 13:53, Kirk Lund wrote:
>
>> Ok #3 makes sense then. It's not that the Cache initialization is broken,
>> it's that some people want to hook in some custom initialization at the
>> end
>> of cache creation but before starting the ClientServer component.
>>
>> I think it would make the most sense to have Cache initialization
>> callbacks
>> (this has been commonly requested by users for as long as I can remember).
>>
>> It would also make sense to add lifecycle control commands for starting
>> and
>> stopping the ClientServer component (since this isn't a workaround for
>> some
>> sinister bug). If we design the start clientserver command correctly then
>> it's one more step towards completing cluster config in such a way that no
>> one needs cache.xml anymore. Right now if a user wants to create multiple
>> ClientServer endpoints then they have to use cache.xml in addition to
>> starting the default-server with the start server command.
>>
>>
>> On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <uk...@pivotal.io>
>> wrote:
>>
>> 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 <ds...@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 <ms...@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
>>>>>>>
>>>>>>>
>>>>>>>
>


-- 
-John
john.blum10101 (skype)

Re: Server accepts clients before its cache is initialized

[Udo Kohlmeyer <uk...@pivotal.io>]

+2


On 1/5/17 13:53, Kirk Lund wrote:
> Ok #3 makes sense then. It's not that the Cache initialization is broken,
> it's that some people want to hook in some custom initialization at the end
> of cache creation but before starting the ClientServer component.
>
> I think it would make the most sense to have Cache initialization callbacks
> (this has been commonly requested by users for as long as I can remember).
>
> It would also make sense to add lifecycle control commands for starting and
> stopping the ClientServer component (since this isn't a workaround for some
> sinister bug). If we design the start clientserver command correctly then
> it's one more step towards completing cluster config in such a way that no
> one needs cache.xml anymore. Right now if a user wants to create multiple
> ClientServer endpoints then they have to use cache.xml in addition to
> starting the default-server with the start server command.
>
>
> On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
>> 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 <ds...@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 <ms...@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
>>>>>>
>>>>>>

Re: Server accepts clients before its cache is initialized

[Kirk Lund <kl...@pivotal.io>]

Ok #3 makes sense then. It's not that the Cache initialization is broken,
it's that some people want to hook in some custom initialization at the end
of cache creation but before starting the ClientServer component.

I think it would make the most sense to have Cache initialization callbacks
(this has been commonly requested by users for as long as I can remember).

It would also make sense to add lifecycle control commands for starting and
stopping the ClientServer component (since this isn't a workaround for some
sinister bug). If we design the start clientserver command correctly then
it's one more step towards completing cluster config in such a way that no
one needs cache.xml anymore. Right now if a user wants to create multiple
ClientServer endpoints then they have to use cache.xml in addition to
starting the default-server with the start server command.


On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:

> 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 <ds...@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 <ms...@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
>>>>>
>>>>>
>

Re: Server accepts clients before its cache is initialized

[Bruce Schuchardt <bs...@pivotal.io>]

I think this is the kind of thing that's wanted, though it would be nice 
to be able to automate it, maybe through cache-server life cycle 
events.  In Geode the cache is always fully initialized prior to 
starting the cache server.

Le 1/5/2017 � 1:30 PM, Dan Smith a �crit :
> Udo - could your use case be satisfied just by doing somthing like this?
>
> 1) gfsh start server --disable-default-server
> 2) Run your custom code
> 3) As the last part of your custom code, call Cache.addCacheServer
>
> -Dan
>
> On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
>> 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 <ds...@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 <ms...@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
>>>>>>
>>>>>>

Re: Server accepts clients before its cache is initialized

[Udo Kohlmeyer <uk...@pivotal.io>]

Yes,

That could work as well.

But in the "nice" way would be to have a mechanism that would allow you 
to hook into the lifecycle and add pre-client-accessible without forcing 
a user to invoke the Cache.addCacheServer.start() code.

Also, there could be cases were you'd like to turn off the ability for 
servers to service client requests. So a manual step to stop the 
cacheServer would be nice. You could do this via a function, but as 
stated, if the JAVA API allows for such capability then it should not be 
that hard to expose it.

--Udo


On 1/5/17 13:30, Dan Smith wrote:
> Udo - could your use case be satisfied just by doing somthing like this?
>
> 1) gfsh start server --disable-default-server
> 2) Run your custom code
> 3) As the last part of your custom code, call Cache.addCacheServer
>
> -Dan
>
> On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
>> 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 <ds...@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 <ms...@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
>>>>>>
>>>>>>

Re: Server accepts clients before its cache is initialized

[Dan Smith <ds...@pivotal.io>]

Udo - could your use case be satisfied just by doing somthing like this?

1) gfsh start server --disable-default-server
2) Run your custom code
3) As the last part of your custom code, call Cache.addCacheServer

-Dan

On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:

> 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 <ds...@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 <ms...@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
>>>>>
>>>>>
>

Re: Server accepts clients before its cache is initialized

[Udo Kohlmeyer <uk...@pivotal.io>]

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 <ds...@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 <ms...@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
>>>>

Re: Server accepts clients before its cache is initialized

[Kirk Lund <kl...@apache.org>]

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 <ds...@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 <ms...@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
> > >
> >
>

Re: Server accepts clients before its cache is initialized

[Dan Smith <ds...@pivotal.io>]

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 <ms...@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
> >
>

Re: Server accepts clients before its cache is initialized

[Michael Stolz <ms...@pivotal.io>]

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
>