+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 t
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 GemFi
+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 h
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
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
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 ab
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 wrote:
> Take this scenario as an
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 serv
-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
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
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 (s
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 wrote:
> So, I'm lookin
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, init
13 matches
Mail list logo
