Quantcast

[infinispan-dev] Persisted state

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Persisted state

Radim Vansa
Hi,

in what situations is the state (ATM just version + cache topologies)
meant to be persisted? I guess it's necessary with non-shared cache
stores, but should it be persisted with shared one, too?

And what are the guarantees during writing that state down? (e.g. can
you make sure that no operations are executed when persisting?)

My problem is that for scattered cache, I need to persist highest
version for each segment, or I have to iterate through cache store when
starting - that's kind of forced preload. It's even worse - during
regular preload, cache topology is not installed yet, and as I've found,
I can't do that in @Start annotated method because I need to find
segment for each key and cache topology can be installed even later than
in STMI.start() (when the persistent state is being loaded, the response
to join may not contain the cache topology).

Radim


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Persisted state

Tristan Tarrant-2
On 28/07/16 15:59, Radim Vansa wrote:
> Hi,
>
> in what situations is the state (ATM just version + cache topologies)
> meant to be persisted? I guess it's necessary with non-shared cache
> stores, but should it be persisted with shared one, too?
The writing is handled by the global state manager. You need to enable
global state first obviously.
There are two types of state: per-cachemanager and per-cache. Also
graceful stop is performed only when a cache is shutdown(), not stop()ed.
> And what are the guarantees during writing that state down? (e.g. can
> you make sure that no operations are executed when persisting?)
That is not how it is being handled atm: rebalancing is disabled, caches
are passivated, and the state is written before stopping the cache
components. It's like this because I was thinking that the state that we
are writing (CH and topology) wouldn't be affected by some additional
operations, but it would make sense to put the cache in a STOPPING state
first to avoid ops.

Tristan
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Persisted state

Radim Vansa
On 07/29/2016 12:40 PM, Tristan Tarrant wrote:

> On 28/07/16 15:59, Radim Vansa wrote:
>> Hi,
>>
>> in what situations is the state (ATM just version + cache topologies)
>> meant to be persisted? I guess it's necessary with non-shared cache
>> stores, but should it be persisted with shared one, too?
> The writing is handled by the global state manager. You need to enable
> global state first obviously.
> There are two types of state: per-cachemanager and per-cache. Also
> graceful stop is performed only when a cache is shutdown(), not stop()ed.

Okay, I see that this needs to be enabled manually through configuration
(which makes sense). I can't find any recommendation to users *when*
they should enable it and therefore, when can the developer expect it to
be set (and emit a warning/error when it is not set).

>> And what are the guarantees during writing that state down? (e.g. can
>> you make sure that no operations are executed when persisting?)
> That is not how it is being handled atm: rebalancing is disabled, caches
> are passivated, and the state is written before stopping the cache
> components. It's like this because I was thinking that the state that we
> are writing (CH and topology) wouldn't be affected by some additional
> operations, but it would make sense to put the cache in a STOPPING state
> first to avoid ops.

Ack, moving the cache to STOPPING state is what I had in mind. I wanted
to know whether it would be 'intended'.

>
> Tristan
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...