[wildfly-dev] Proposal: Availability subsystem

[Rodakr]

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" <david.lloyd at redhat.com>:

> 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
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev