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 redhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
|
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.stansberryredhat.com
>>
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manikjboss.org
> Telephone: +44 7786 702 706
> MSN: maniksurtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
|