Proposal: Availability subsystem

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Availability subsystem

David Lloyd-2
I've been sitting on this idea for a while so I thought I'd put it out
there and get some feedback on it.

Problem: People want things to happen when the container is "up".
Unfortunately, there really isn't a black-and-white concept for what
"up" means.  Often times, the user is simply going for "my application
will function correctly", so they can make a load-balancing decision or
perform some other monitoring action.

Semantically, the desire would be for some external mechanism to receive
a notification when the services corresponding to the specifically
applicable components have completely started or are going to stop.  The
obvious implementation of such a mechanism is a service which depends on
the set of component services.

Solution 1: In theory, a user could create a deployment that performs
availability tasks in a service which depends on all the requisite
services.  The user needs specific knowledge of service names in this
case, which may change, or they must use specific technologies (for
example, use a singleton EJB which @DependsOn each dependency).

Solution 2: Introduce a subsystem which allows definition of different
availability configurations.  The configuration would enumerate the
items that are required for the configuration to be considered
available.  The configuration would be associated with an action.  We
would use management.next-style extensibility points to let the user
define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
without the subsystem needing specific knowledge of the service schemes
for each.

We could make solution 1 work more effectively by providing a more
uniform deployment-based dependency mechanism, but that seems more
complex to me than just introducing a subsystem and SPI for this purpose.

With a subsystem we could bundle actions for things like mod_cluster,
other potential future Undertow- and Remoting-based proxies, simple
notification schemes like MBean notification or logging, POST
notification, and so on.

The timeline would not be 8 (obviously), nor 9.  I think having the
simplified management SPI in place is a definite prerequisite, else the
effort/reward ratio is far too low to justify doing this.  Otherwise, I
think this is a simple idea that could be pretty damn useful, so I want
to put it out here so it's in the back of everyone's mind.
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Availability subsystem

Radoslaw Rodak
Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define  container "up" mabe.



Von meinem iPhone gesendet

Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <[hidden email]>:

> I've been sitting on this idea for a while so I thought I'd put it out
> there and get some feedback on it.
>
> Problem: People want things to happen when the container is "up".
> Unfortunately, there really isn't a black-and-white concept for what
> "up" means.  Often times, the user is simply going for "my application
> will function correctly", so they can make a load-balancing decision or
> perform some other monitoring action.
>
> Semantically, the desire would be for some external mechanism to receive
> a notification when the services corresponding to the specifically
> applicable components have completely started or are going to stop.  The
> obvious implementation of such a mechanism is a service which depends on
> the set of component services.
>
> Solution 1: In theory, a user could create a deployment that performs
> availability tasks in a service which depends on all the requisite
> services.  The user needs specific knowledge of service names in this
> case, which may change, or they must use specific technologies (for
> example, use a singleton EJB which @DependsOn each dependency).
>
> Solution 2: Introduce a subsystem which allows definition of different
> availability configurations.  The configuration would enumerate the
> items that are required for the configuration to be considered
> available.  The configuration would be associated with an action.  We
> would use management.next-style extensibility points to let the user
> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
> without the subsystem needing specific knowledge of the service schemes
> for each.
>
> We could make solution 1 work more effectively by providing a more
> uniform deployment-based dependency mechanism, but that seems more
> complex to me than just introducing a subsystem and SPI for this purpose.
>
> With a subsystem we could bundle actions for things like mod_cluster,
> other potential future Undertow- and Remoting-based proxies, simple
> notification schemes like MBean notification or logging, POST
> notification, and so on.
>
> The timeline would not be 8 (obviously), nor 9.  I think having the
> simplified management SPI in place is a definite prerequisite, else the
> effort/reward ratio is far too low to justify doing this.  Otherwise, I
> think this is a simple idea that could be pretty damn useful, so I want
> to put it out here so it's in the back of everyone's mind.
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

Re: Proposal: Availability subsystem

David Lloyd-2
The problem is that deployments may be added and removed at any time, as
can other server ports and services.  The case that this causes a
problem is where a server starts up, mistakenly without an essential
deployment, and the server thinks it's "up" but actually a required part
is missing, possibly causing the end user to observe a "broken" server.

On 01/30/2014 05:54 PM, Rodakr wrote:

> Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define  container "up" mabe.
>
>
>
> Von meinem iPhone gesendet
>
> Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <[hidden email]>:
>
>> I've been sitting on this idea for a while so I thought I'd put it out
>> there and get some feedback on it.
>>
>> Problem: People want things to happen when the container is "up".
>> Unfortunately, there really isn't a black-and-white concept for what
>> "up" means.  Often times, the user is simply going for "my application
>> will function correctly", so they can make a load-balancing decision or
>> perform some other monitoring action.
>>
>> Semantically, the desire would be for some external mechanism to receive
>> a notification when the services corresponding to the specifically
>> applicable components have completely started or are going to stop.  The
>> obvious implementation of such a mechanism is a service which depends on
>> the set of component services.
>>
>> Solution 1: In theory, a user could create a deployment that performs
>> availability tasks in a service which depends on all the requisite
>> services.  The user needs specific knowledge of service names in this
>> case, which may change, or they must use specific technologies (for
>> example, use a singleton EJB which @DependsOn each dependency).
>>
>> Solution 2: Introduce a subsystem which allows definition of different
>> availability configurations.  The configuration would enumerate the
>> items that are required for the configuration to be considered
>> available.  The configuration would be associated with an action.  We
>> would use management.next-style extensibility points to let the user
>> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
>> without the subsystem needing specific knowledge of the service schemes
>> for each.
>>
>> We could make solution 1 work more effectively by providing a more
>> uniform deployment-based dependency mechanism, but that seems more
>> complex to me than just introducing a subsystem and SPI for this purpose.
>>
>> With a subsystem we could bundle actions for things like mod_cluster,
>> other potential future Undertow- and Remoting-based proxies, simple
>> notification schemes like MBean notification or logging, POST
>> notification, and so on.
>>
>> The timeline would not be 8 (obviously), nor 9.  I think having the
>> simplified management SPI in place is a definite prerequisite, else the
>> effort/reward ratio is far too low to justify doing this.  Otherwise, I
>> think this is a simple idea that could be pretty damn useful, so I want
>> to put it out here so it's in the back of everyone's mind.
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Availability subsystem

Nicklas Karlsson
There is apparently no work going on in any related EE JSR that is covering this? 
One would think most application servers could benefit from this.


On Fri, Jan 31, 2014 at 2:47 AM, David M. Lloyd <[hidden email]> wrote:
The problem is that deployments may be added and removed at any time, as
can other server ports and services.  The case that this causes a
problem is where a server starts up, mistakenly without an essential
deployment, and the server thinks it's "up" but actually a required part
is missing, possibly causing the end user to observe a "broken" server.

On 01/30/2014 05:54 PM, Rodakr wrote:
> Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define  container "up" mabe.
>
>
>
> Von meinem iPhone gesendet
>
> Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <[hidden email]>:
>
>> I've been sitting on this idea for a while so I thought I'd put it out
>> there and get some feedback on it.
>>
>> Problem: People want things to happen when the container is "up".
>> Unfortunately, there really isn't a black-and-white concept for what
>> "up" means.  Often times, the user is simply going for "my application
>> will function correctly", so they can make a load-balancing decision or
>> perform some other monitoring action.
>>
>> Semantically, the desire would be for some external mechanism to receive
>> a notification when the services corresponding to the specifically
>> applicable components have completely started or are going to stop.  The
>> obvious implementation of such a mechanism is a service which depends on
>> the set of component services.
>>
>> Solution 1: In theory, a user could create a deployment that performs
>> availability tasks in a service which depends on all the requisite
>> services.  The user needs specific knowledge of service names in this
>> case, which may change, or they must use specific technologies (for
>> example, use a singleton EJB which @DependsOn each dependency).
>>
>> Solution 2: Introduce a subsystem which allows definition of different
>> availability configurations.  The configuration would enumerate the
>> items that are required for the configuration to be considered
>> available.  The configuration would be associated with an action.  We
>> would use management.next-style extensibility points to let the user
>> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
>> without the subsystem needing specific knowledge of the service schemes
>> for each.
>>
>> We could make solution 1 work more effectively by providing a more
>> uniform deployment-based dependency mechanism, but that seems more
>> complex to me than just introducing a subsystem and SPI for this purpose.
>>
>> With a subsystem we could bundle actions for things like mod_cluster,
>> other potential future Undertow- and Remoting-based proxies, simple
>> notification schemes like MBean notification or logging, POST
>> notification, and so on.
>>
>> The timeline would not be 8 (obviously), nor 9.  I think having the
>> simplified management SPI in place is a definite prerequisite, else the
>> effort/reward ratio is far too low to justify doing this.  Otherwise, I
>> think this is a simple idea that could be pretty damn useful, so I want
>> to put it out here so it's in the back of everyone's mind.
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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



--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

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

Re: Proposal: Availability subsystem

Pete Muir
I have raised this with the Java EE EG before, and there is no desire to standardise something like this.

On 31 Jan 2014, at 12:07, Nicklas Karlsson <[hidden email]> wrote:

> There is apparently no work going on in any related EE JSR that is covering this?
> One would think most application servers could benefit from this.
>
>
> On Fri, Jan 31, 2014 at 2:47 AM, David M. Lloyd <[hidden email]> wrote:
> The problem is that deployments may be added and removed at any time, as
> can other server ports and services.  The case that this causes a
> problem is where a server starts up, mistakenly without an essential
> deployment, and the server thinks it's "up" but actually a required part
> is missing, possibly causing the end user to observe a "broken" server.
>
> On 01/30/2014 05:54 PM, Rodakr wrote:
> > Having state machine which set the state from "Starting" to "Running" after all ressources has been initialized, all deployments are finished and server ports are listening could help to define  container "up" mabe.
> >
> >
> >
> > Von meinem iPhone gesendet
> >
> > Am 30.01.2014 um 22:15 schrieb "David M. Lloyd" <[hidden email]>:
> >
> >> I've been sitting on this idea for a while so I thought I'd put it out
> >> there and get some feedback on it.
> >>
> >> Problem: People want things to happen when the container is "up".
> >> Unfortunately, there really isn't a black-and-white concept for what
> >> "up" means.  Often times, the user is simply going for "my application
> >> will function correctly", so they can make a load-balancing decision or
> >> perform some other monitoring action.
> >>
> >> Semantically, the desire would be for some external mechanism to receive
> >> a notification when the services corresponding to the specifically
> >> applicable components have completely started or are going to stop.  The
> >> obvious implementation of such a mechanism is a service which depends on
> >> the set of component services.
> >>
> >> Solution 1: In theory, a user could create a deployment that performs
> >> availability tasks in a service which depends on all the requisite
> >> services.  The user needs specific knowledge of service names in this
> >> case, which may change, or they must use specific technologies (for
> >> example, use a singleton EJB which @DependsOn each dependency).
> >>
> >> Solution 2: Introduce a subsystem which allows definition of different
> >> availability configurations.  The configuration would enumerate the
> >> items that are required for the configuration to be considered
> >> available.  The configuration would be associated with an action.  We
> >> would use management.next-style extensibility points to let the user
> >> define add-in items like EJBs, servlets, POJOs, MBeans, CDI beans, etc.
> >> without the subsystem needing specific knowledge of the service schemes
> >> for each.
> >>
> >> We could make solution 1 work more effectively by providing a more
> >> uniform deployment-based dependency mechanism, but that seems more
> >> complex to me than just introducing a subsystem and SPI for this purpose.
> >>
> >> With a subsystem we could bundle actions for things like mod_cluster,
> >> other potential future Undertow- and Remoting-based proxies, simple
> >> notification schemes like MBean notification or logging, POST
> >> notification, and so on.
> >>
> >> The timeline would not be 8 (obviously), nor 9.  I think having the
> >> simplified management SPI in place is a definite prerequisite, else the
> >> effort/reward ratio is far too low to justify doing this.  Otherwise, I
> >> think this is a simple idea that could be pretty damn useful, so I want
> >> to put it out here so it's in the back of everyone's mind.
> >> --
> >> - DML
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


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