[jbosscache-dev] JBCACHE-928 (lifecycle state)

[Brian Stansberry]

There's a LifecycleState enum (I like CacheStatus better):

INSTANTIATED, CREATED, STARTING, STARTED, STOPPING, STOPPED, DESTROYED, 
FAILED.

These basically map to the old ServiceMBean states from AS 4, except 
those have JMX Microkernel-centric UNREGISTERED/REGISTERED which I 
merged into INSTANTIATED.  In AS 4.x FAILED means a failed transition 
from CREATED to STARTED or STARTED to STOPPED.

It's not beautiful, i.e. logical holes like CREATING/DESTROYING, plus 
what FAILED means is indeterminate. I think the original thinking on 
that in AS 4 was that create() and destroy() do things that can be 
repeated, whereas a failure in start/stop mean you have to start over 
from create.

Also, in AS 4 and JBC 1.x, when the cache underwent a state transition 
it would send out a JMX notification using the old ServiceMBean states 
as a value.  There's code in the AS that listens for those notifications 
and translates them into the JSR-77 states of STARTING, RUNNING, 
STOPPING, STOPPED, or FAILED.  I plan to implement that, but probably 
not until CR3.

Hmm... I see now for that JSR-77 stuff to fully work, the mbean needs to 
expose an attribute with the name "State".  Ugly name. But that's just 
something that the CacheJmxWrapper should expose. If we add a property 
to Cache it can be named whatever we like.

Manik Surtani wrote:
> I think it does make sense to do it now that we have lifecycle tracking 
> anyway.
> 
> Perhaps an Enum - CacheStatus { UNINITIALISED, INITIALISED, STARTED, 
> STOPPED, DESTROYED }.  Do we want transitional states as well - 
> INITIALISING, STARTING, STOPPING, DESTROYING?
> 
> 
> On 22 May 2007, at 21:40, Brian Stansberry wrote:
> 
>> Manik,
>>
>> Resurrecting an old thread so I can finish up JBCACHE-1058.
>>
>> As part of the JBCACHE-1058 work, I've added functionality to 
>> CacheImpl where it tracks what lifecycle stage it's in. Issue then is 
>> whether we want to expose that as part of the Cache API.
>>
>> Below it seems like we decided we didn't want to do that, but not sure 
>> if that was just because we didn't want to implement the lifecycle 
>> tracking. Which is now done.
>>
>> Let me know what you'd like; it's 30 seconds work either way.
>>
>> "Brian Stansberry" wrote:
>>> Manik Surtani wrote:
>>>> On 11 Jan 2007, at 15:33, Brian Stansberry wrote:
>>>>
>>>>> I should have discussed this before opening JIRA, since the use case
>>>>> isn't clear, but...
>>>>> Exposure in JMX makes sense, since we expose the lifecycle
>>>>> operations, i.e. you stop the cache and your colleague comes and
>>>>> bugs you, it's nice to be able to see the state it's in when you get
>>>>> back to work.
>>>>> I *believe* (pretty sure actually) in AS 5 the MC will uninstall a
>>>>> bean if it fails in deployment, and this will include deregistering
>>>>> from JMX. So, the AS 4.x use case of being able to see the status of
>>>>> a failed deployment in the JMX console probably doesn't apply.
>>>>>
>>>>> Are there situations where the cache lifecycle can change internally?
>>>>> For example, as a result of the channel being shunned and auto-
>>>>> closing? Right now we don't handle that, but if we did, is it
>>>>> possible it would trigger a lifecycle transition?
>>>>
>>>> True.  At the moment though this is not the case.  But since
>>>> this is just an addition of an API, perhaps we add it later when we
>>>> have the need?
>>> +1. I reread the JIRA and it's to "consider" the issue.  By Beta1, 
>>> since it impacts API.  We've now considered it, so pushing it out to 
>>> some future point is fine by me. :-)
>>> - Brian
>>
>>
>> --Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> brian.stansberry at redhat.com
>>
> 
> -- 
> Manik Surtani
> 
> Lead, JBoss Cache
> JBoss, a division of Red Hat
> 
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
> 
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com