May 2007 - jbosscache-dev - Jboss List Archives

jboss-cache-testsuite-jdk16 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

jboss-cache build.1058 Build Successful

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

jboss-cache build.1057 Build Successful

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

jboss-cache-testsuite-140 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

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

by 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(a)redhat.com >> > > -- > Manik Surtani > > Lead, JBoss Cache > JBoss, a division of Red Hat > > Email: manik(a)jboss.org > Telephone: +44 7786 702 706 > MSN: manik(a)surtani.org > Yahoo/AIM/Skype: maniksurtani > > -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com

19 years

1
0
0 / 0

jboss-cache-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

jboss-cache-testsuite-jdk14 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

jboss-cache-testsuite-jdk16 Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

jboss-cache build.1056 Build Successful

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

jboss-cache build.1055 Build Successful

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-dev May 2007