[jboss-as7-dev] Detyped API document feedback

[David M. Lloyd]

On 01/04/2011 02:17 PM, Brian Stansberry wrote:
> Responding to the simple bit first...
[..]
> [1] If, as we've discussed, the update handler only uses the update
> parameters and the current runtime state when applying the update (and
> ignores the current values in the model), then some attempt at
> re-applying the update to the runtime is possible.

Sure, there are a few avenues we could go down here.  With the new, more 
decoupled architecture we could conceivably use an intermediate runtime 
change execution object which can contain additional state beyond what 
was in the original update for example.  This way the operation handlers 
can access the model at will - even if it's not a model update - and use 
that information to help out at runtime.

In other words, there would be an operation handler which is a singleton 
for each operation, which yields zero or one (or more?) command objects 
to be executed to carry out the actual change, along with any 
information about the result of the model update.

If a restart is pending, these command objects could simply be discarded 
by the server controller.  A simple flag could be used to tell the 
update handler whether it's running at boot time or not; or, if it is 
still the case that boot time updates need more information to apply 
themselves (i.e. they need to add DUPs), we could discriminate update 
type based on command object type (boot updates would only run at boot 
time; other updates are run at all times).  Or some combination if we 
were very keen on avoiding the overhead of creating extra objects that 
just end up being discarded in certain circumstances.

Either way I think that most failed runtime updates are fixable, but 
some are not, and simply re-applying the update usually won't work in 
any case; however rolling back isn't the only option either.  Problems 
fall into a number of categories:

1. Parameter validation problems.  These should *really* be picked up by 
the model updater but there may be cases where it is too complex to do 
so.  In this case, re-applying the update won't help by itself but 
applying a "repairing" update with a valid value might.  This might be 
preferable to undoing a complicated update.

2. Dependency problems.  You've added a service that requires another 
service which isn't active for some reason, or perhaps there's a 
dependency on a deployment which is deliberately administratively 
disabled.  This can be fixed by adding the missing dependency in another 
update, or by activating the disabled deployment, and might even be an 
expected result as a part of a multi-phase rollout.

3. Transient runtime issues.  Some admin running a python script which 
bound a port that the AS needs.  The fix is to kill the python script 
and "retry" the failed service via MSC (via the management API, 
presumably).  Rolling back is probably not what the admin wants to do in 
this case.  Re-applying the change might also fix this issue but it's 
technically overkill and might be less reliable just due to being a more 
complex operation overall.

4. Permanent runtime issues.  The computer's HDD started on fire and now 
EIO is flying all over the place.  The problem can't be fixed by rolling 
back; the server has to be taken offline and/or replaced.  But in many 
domain situations, the deployment could otherwise continue as if the 
server were no longer online.  It would take a human to make this 
judgment call.

5. Deployment issues.  A deployment was added which has some invalid 
value combination in one of its descriptors.  Such a deployment can 
never succeed by itself; it needs to either be replaced (rolled back) or 
adjusted somehow (content overlays?) to be made valid.

...and probably dozens of other scenarios I can't think of; either way I 
don't think reapplying an update will very often be the best recourse.

-- 
- DML