When John have changed datasources subsystem he have created 4 operations for them: - add - remove - enable - disable I like them, now Heiko is asking to move enable/disable out in favour of a more standard r/w attribute enabled (note that this attribute is present in our xml). See There: https://issues.jboss.org/browse/JBAS-9341 Since the operation don't just change the attribute, but also stop services and unbind ds from jndi I'd prefer to keep operations as is. I think an explicit operation make clearer to users that they are changing the status of the entire datasourrce opinions? S. _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Graceful shutdown will probably have to work somewhat differently than that. Generally the service simply stays available until nothing is using it (or depending on it) anymore. For example if I have a data source being used by 3 EJBs, the data source is available until all the EJBs are shut down and/or undeployed. And the EJBs are available until all their clients are shut down and/or undeployed, and so on down the line. Having services start refusing requests makes shutdown be not very graceful - it generally just results in error messages for users. By using the dependency system, in combination with clustering or load balancing, the user experience is always smooth and we avoid errors and broken transactions and that sort of thing. On 04/20/2011 05:55 PM, Jim Tyrrell wrote: > Should like in web traffic routing for clustering their be a stopped stage: > add - adds > remove - kills it > enable - means it can accept new connections > disable - mean no new requests > stopped - means no request at all > > Jim Tyrrell > Senior JBoss Solutions Architect > > Did you see RHT on CNBC's Mad Money? > http://www.cnbc.com/id/39401056 > > > > On Apr 20, 2011, at 8:31 AM, Stefano Maestri wrote: > >> When John have changed datasources subsystem he have created 4 >> operations for them: >> - add >> - remove >> - enable >> - disable >> >> I like them, now Heiko is asking to move enable/disable out in favour of >> a more standard r/w attribute enabled (note that this attribute is >> present in our xml). See There: >> >> https://issues.jboss.org/browse/JBAS-9341 >> >> Since the operation don't just change the attribute, but also stop >> services and unbind ds from jndi I'd prefer to keep operations as is. I >> think an explicit operation make clearer to users that they are changing >> the status of the entire datasourrce >> >> opinions? >> >> S. >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I think it would be useful to separate states, state transitions, and user interface actions. One way to model this is to say the states are: started -- accepting all requests disabled -- accepting all requests associated with existing work (in this case "existing work" == uncommitted transactions for which the DS has done work) but rejecting all other requests stopped -- not accepting requests The user interface actions are to trigger a transition between those states. When the service is in the "disabled" state, the user monitors it for the # of open transactions and then moves it to the stopped state when conditions are acceptable. If the user doesn't wish to go to that effort, their initial action triggers a direct move to "stopped" which results in non-graceful behavior. The negative to this approach is if the default workflow is to gracefully get from started to stopped, the user has to take a number of actions to get there. Another way to model this is to see "disabled" as the behavior of a service that is *transitioning* from "started" to "stopped". The end goal for the user is always to get to "stopped", and the default is for that to be graceful. The extra user interface action needed here then is the ability to force the service to abandon the attempt to be graceful and proceed directly to "stopped." This is doing by adding an overloaded variant to the action that triggers the move to "stopped" that accepts a timeout. A timeout of 0 means don't spend any more time trying to be graceful. (Perhaps so syntactic sugar like "stop-now" could be laid on top of the 0 timeout.) The overloaded variant can be used as the initial action (if the user knows how long they are willing to wait) or to force an ongoing transition to "stopped" to complete. This latter approach is how we're trying to do things in AS 7. This has mostly been discussed in the context of server shutdowns, but the way the individual service implementations would handle it should allow same workflow to be applied on a more fine grained basis, if the subsystem developers choose to expose it. On 4/20/11 8:34 PM, Jim Tyrrell wrote: > But in a clustered example you could fail over to another node that > still had that service available, so you would not get errors. > > What if you wanted to gracefully update a datasource, what do you > purpose? To keep as near to 100% uptime as possible. IE the database has > not changed, the app has not changed, but in the back is a Oracle RAC > that can now handle double the amount of threads? You have four machines > that need to be updated. > > I would think you would want to disable the node datasource, then stop > the node datasource. Edit the config, and then start it back up, along > with some pretty tooling that lets you know no more transactions are > pending on that datasource before you stop it. In a perfect world this > is all automated in some tooling to give you 100% uptime and quicesing a > server. > > I fail to see how the paradigm of the web container load balancer does > not apply, I freely admit I am stupid, but your answer to me confirms > that it would apply. > > Jim Tyrrell > Senior JBoss Solutions Architect > > Did you see RHT on CNBC's Mad Money? > http://www.cnbc.com/id/39401056 > > > > On Apr 20, 2011, at 5:29 PM, David M. Lloyd wrote: > >> Graceful shutdown will probably have to work somewhat differently than >> that. Generally the service simply stays available until nothing is >> using it (or depending on it) anymore. For example if I have a data >> source being used by 3 EJBs, the data source is available until all the >> EJBs are shut down and/or undeployed. And the EJBs are available until >> all their clients are shut down and/or undeployed, and so on down the >> line. >> >> Having services start refusing requests makes shutdown be not very >> graceful - it generally just results in error messages for users. By >> using the dependency system, in combination with clustering or load >> balancing, the user experience is always smooth and we avoid errors and >> broken transactions and that sort of thing. >> >> On 04/20/2011 05:55 PM, Jim Tyrrell wrote: >>> Should like in web traffic routing for clustering their be a stopped >>> stage: >>> add - adds >>> remove - kills it >>> enable - means it can accept new connections >>> disable - mean no new requests >>> stopped - means no request at all >>> >>> Jim Tyrrell >>> Senior JBoss Solutions Architect >>> >>> Did you see RHT on CNBC's Mad Money? >>> http://www.cnbc.com/id/39401056 >>> >>> >>> >>> On Apr 20, 2011, at 8:31 AM, Stefano Maestri wrote: >>> >>>> When John have changed datasources subsystem he have created 4 >>>> operations for them: >>>> - add >>>> - remove >>>> - enable >>>> - disable >>>> >>>> I like them, now Heiko is asking to move enable/disable out in favour of >>>> a more standard r/w attribute enabled (note that this attribute is >>>> present in our xml). See There: >>>> >>>> https://issues.jboss.org/browse/JBAS-9341 >>>> >>>> Since the operation don't just change the attribute, but also stop >>>> services and unbind ds from jndi I'd prefer to keep operations as is. I >>>> think an explicit operation make clearer to users that they are changing >>>> the status of the entire datasourrce >>>> >>>> opinions? >>>> >>>> S. >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> -- >> - DML >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I think 'disabled' carries the wrong meaning. Isn't 'disabled' really what we have been modeling as 'stopping' ? On 21/04/2011 16:08, Brian Stansberry wrote: > I think it would be useful to separate states, state transitions, and > user interface actions. > > One way to model this is to say the states are: > > started -- accepting all requests > disabled -- accepting all requests associated with existing work (in > this case "existing work" == uncommitted transactions for which the DS > has done work) but rejecting all other requests > stopped -- not accepting requests > > The user interface actions are to trigger a transition between those > states. When the service is in the "disabled" state, the user monitors > it for the # of open transactions and then moves it to the stopped state > when conditions are acceptable. If the user doesn't wish to go to that > effort, their initial action triggers a direct move to "stopped" which > results in non-graceful behavior. > > The negative to this approach is if the default workflow is to > gracefully get from started to stopped, the user has to take a number of > actions to get there. > > Another way to model this is to see "disabled" as the behavior of a > service that is *transitioning* from "started" to "stopped". The end > goal for the user is always to get to "stopped", and the default is for > that to be graceful. The extra user interface action needed here then is > the ability to force the service to abandon the attempt to be graceful > and proceed directly to "stopped." This is doing by adding an overloaded > variant to the action that triggers the move to "stopped" that accepts a > timeout. A timeout of 0 means don't spend any more time trying to be > graceful. (Perhaps so syntactic sugar like "stop-now" could be laid on > top of the 0 timeout.) The overloaded variant can be used as the initial > action (if the user knows how long they are willing to wait) or to force > an ongoing transition to "stopped" to complete. > > This latter approach is how we're trying to do things in AS 7. This has > mostly been discussed in the context of server shutdowns, but the way > the individual service implementations would handle it should allow same > workflow to be applied on a more fine grained basis, if the subsystem > developers choose to expose it. > > On 4/20/11 8:34 PM, Jim Tyrrell wrote: >> But in a clustered example you could fail over to another node that >> still had that service available, so you would not get errors. >> >> What if you wanted to gracefully update a datasource, what do you >> purpose? To keep as near to 100% uptime as possible. IE the database has >> not changed, the app has not changed, but in the back is a Oracle RAC >> that can now handle double the amount of threads? You have four machines >> that need to be updated. >> >> I would think you would want to disable the node datasource, then stop >> the node datasource. Edit the config, and then start it back up, along >> with some pretty tooling that lets you know no more transactions are >> pending on that datasource before you stop it. In a perfect world this >> is all automated in some tooling to give you 100% uptime and quicesing a >> server. >> >> I fail to see how the paradigm of the web container load balancer does >> not apply, I freely admit I am stupid, but your answer to me confirms >> that it would apply. >> >> Jim Tyrrell >> Senior JBoss Solutions Architect >> >> Did you see RHT on CNBC's Mad Money? >> http://www.cnbc.com/id/39401056 >> >> >> >> On Apr 20, 2011, at 5:29 PM, David M. Lloyd wrote: >> >>> Graceful shutdown will probably have to work somewhat differently than >>> that. Generally the service simply stays available until nothing is >>> using it (or depending on it) anymore. For example if I have a data >>> source being used by 3 EJBs, the data source is available until all the >>> EJBs are shut down and/or undeployed. And the EJBs are available until >>> all their clients are shut down and/or undeployed, and so on down the >>> line. >>> >>> Having services start refusing requests makes shutdown be not very >>> graceful - it generally just results in error messages for users. By >>> using the dependency system, in combination with clustering or load >>> balancing, the user experience is always smooth and we avoid errors and >>> broken transactions and that sort of thing. >>> >>> On 04/20/2011 05:55 PM, Jim Tyrrell wrote: >>>> Should like in web traffic routing for clustering their be a stopped >>>> stage: >>>> add - adds >>>> remove - kills it >>>> enable - means it can accept new connections >>>> disable - mean no new requests >>>> stopped - means no request at all >>>> >>>> Jim Tyrrell >>>> Senior JBoss Solutions Architect >>>> >>>> Did you see RHT on CNBC's Mad Money? >>>> http://www.cnbc.com/id/39401056 >>>> >>>> >>>> >>>> On Apr 20, 2011, at 8:31 AM, Stefano Maestri wrote: >>>> >>>>> When John have changed datasources subsystem he have created 4 >>>>> operations for them: >>>>> - add >>>>> - remove >>>>> - enable >>>>> - disable >>>>> >>>>> I like them, now Heiko is asking to move enable/disable out in favour of >>>>> a more standard r/w attribute enabled (note that this attribute is >>>>> present in our xml). See There: >>>>> >>>>> https://issues.jboss.org/browse/JBAS-9341 >>>>> >>>>> Since the operation don't just change the attribute, but also stop >>>>> services and unbind ds from jndi I'd prefer to keep operations as is. I >>>>> think an explicit operation make clearer to users that they are changing >>>>> the status of the entire datasourrce >>>>> >>>>> opinions? >>>>> >>>>> S. >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > >

How about a state in which we only accept internal requests? The problem that needs to be solved is the EJB (/Component) that starts to query a DS (or other EJB) after the shutdown request has been posted. Carlo On 04/21/2011 03:08 PM, Brian Stansberry wrote: > I think it would be useful to separate states, state transitions, and > user interface actions. > > One way to model this is to say the states are: > > started -- accepting all requests > disabled -- accepting all requests associated with existing work (in > this case "existing work" == uncommitted transactions for which the DS > has done work) but rejecting all other requests > stopped -- not accepting requests > > The user interface actions are to trigger a transition between those > states. When the service is in the "disabled" state, the user monitors > it for the # of open transactions and then moves it to the stopped state > when conditions are acceptable. If the user doesn't wish to go to that > effort, their initial action triggers a direct move to "stopped" which > results in non-graceful behavior. > > The negative to this approach is if the default workflow is to > gracefully get from started to stopped, the user has to take a number of > actions to get there. > > Another way to model this is to see "disabled" as the behavior of a > service that is *transitioning* from "started" to "stopped". The end > goal for the user is always to get to "stopped", and the default is for > that to be graceful. The extra user interface action needed here then is > the ability to force the service to abandon the attempt to be graceful > and proceed directly to "stopped." This is doing by adding an overloaded > variant to the action that triggers the move to "stopped" that accepts a > timeout. A timeout of 0 means don't spend any more time trying to be > graceful. (Perhaps so syntactic sugar like "stop-now" could be laid on > top of the 0 timeout.) The overloaded variant can be used as the initial > action (if the user knows how long they are willing to wait) or to force > an ongoing transition to "stopped" to complete. > > This latter approach is how we're trying to do things in AS 7. This has > mostly been discussed in the context of server shutdowns, but the way > the individual service implementations would handle it should allow same > workflow to be applied on a more fine grained basis, if the subsystem > developers choose to expose it. > > On 4/20/11 8:34 PM, Jim Tyrrell wrote: >> But in a clustered example you could fail over to another node that >> still had that service available, so you would not get errors. >> >> What if you wanted to gracefully update a datasource, what do you >> purpose? To keep as near to 100% uptime as possible. IE the database has >> not changed, the app has not changed, but in the back is a Oracle RAC >> that can now handle double the amount of threads? You have four machines >> that need to be updated. >> >> I would think you would want to disable the node datasource, then stop >> the node datasource. Edit the config, and then start it back up, along >> with some pretty tooling that lets you know no more transactions are >> pending on that datasource before you stop it. In a perfect world this >> is all automated in some tooling to give you 100% uptime and quicesing a >> server. >> >> I fail to see how the paradigm of the web container load balancer does >> not apply, I freely admit I am stupid, but your answer to me confirms >> that it would apply. >> >> Jim Tyrrell >> Senior JBoss Solutions Architect >> >> Did you see RHT on CNBC's Mad Money? >> http://www.cnbc.com/id/39401056 >> >> >> >> On Apr 20, 2011, at 5:29 PM, David M. Lloyd wrote: >> >>> Graceful shutdown will probably have to work somewhat differently than >>> that. Generally the service simply stays available until nothing is >>> using it (or depending on it) anymore. For example if I have a data >>> source being used by 3 EJBs, the data source is available until all the >>> EJBs are shut down and/or undeployed. And the EJBs are available until >>> all their clients are shut down and/or undeployed, and so on down the >>> line. >>> >>> Having services start refusing requests makes shutdown be not very >>> graceful - it generally just results in error messages for users. By >>> using the dependency system, in combination with clustering or load >>> balancing, the user experience is always smooth and we avoid errors and >>> broken transactions and that sort of thing. >>> >>> On 04/20/2011 05:55 PM, Jim Tyrrell wrote: >>>> Should like in web traffic routing for clustering their be a stopped >>>> stage: >>>> add - adds >>>> remove - kills it >>>> enable - means it can accept new connections >>>> disable - mean no new requests >>>> stopped - means no request at all >>>> >>>> Jim Tyrrell >>>> Senior JBoss Solutions Architect >>>> >>>> Did you see RHT on CNBC's Mad Money? >>>> http://www.cnbc.com/id/39401056 >>>> >>>> >>>> >>>> On Apr 20, 2011, at 8:31 AM, Stefano Maestri wrote: >>>> >>>>> When John have changed datasources subsystem he have created 4 >>>>> operations for them: >>>>> - add >>>>> - remove >>>>> - enable >>>>> - disable >>>>> >>>>> I like them, now Heiko is asking to move enable/disable out in favour of >>>>> a more standard r/w attribute enabled (note that this attribute is >>>>> present in our xml). See There: >>>>> >>>>> https://issues.jboss.org/browse/JBAS-9341 >>>>> >>>>> Since the operation don't just change the attribute, but also stop >>>>> services and unbind ds from jndi I'd prefer to keep operations as is. I >>>>> think an explicit operation make clearer to users that they are changing >>>>> the status of the entire datasourrce >>>>> >>>>> opinions? >>>>> >>>>> S. >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> -- >>> - DML >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I think offering both variants is fine too.

On 4/21/11 3:01 AM, Heiko Braun wrote: > > Both variants are fine. I can also understand the attempt to > distinguish operation vs attribute use cases. > > IMO this reveals one of the weak sports in the detyped API: > runtime vs. configuration properties of the system. > > to further distinguish these two I would suggest the following, > which may apply to other subsystems as well: > > - if changing the configuration impacts the runtime state (i.e. enabled->disabled) > then make it an operation > - if it's merely configuration then make it an attribute > I'm fine with this, but let's clarify what "impacts the runtime state" means. Many configuration changes will impact the runtime state. Instead of "impacts the runtime state" I'd say "results in an MSC service starting or stopping." That's the main case where an action has rippling effects the user might not anticipate