[wildfly-dev] Proposal: Availability subsystem

[David M. Lloyd]

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