[jboss-as7-dev] Management proposal for attribute mutability

[Jason T. Greene]

On 8/22/11 1:42 PM, Jason T. Greene wrote:
> On 8/22/11 1:26 PM, Brian Stansberry wrote:
>> On 8/2/11 4:22 PM, Jason T. Greene wrote:
>>> Currently we have way too many read only attributes in our management
>>> model. This makes life harder for the management tools and/or makes the
>>> resulting UI a bit unwieldy.
>>>
>>> In some cases this is just because we haven't polished subsystem
>>> management (PLEASE all subsystem authors look at this!). In other cases
>>> though it's intentional because it is either difficult or currently
>>> impossible to make hot changes to a particular attribute. This should be
>>> exceedingly rare. Users love hot updates, and it's a competitive
>>> advantage. So first we should strive to make it hot in the first place.
>>>
>>> However in the case that the change is not hot, and a server reboot is
>>> too aggressive, we should still supporting making the changes by
>>> bouncing all services involved. After some debate on IRC we finally
>>> arrived at what is IMO a really good option for this problem:
>>>
>>> write-attribute (impact-services=true|false)
>>>
>>> The operation handler on such a non-hot attribute would then return an
>>> error
>>
>> A handler should not return an error if a change cannot be applied to
>> the runtime. An OperationStepHandler should use the relevant API on the
>> OperationContext. E.g. for a handler registered for Stage.RUNTIME:
>>
>> @Override
>> public void execute(OperationContext context, ModelNode operation) {
>>
>>      context.runtimeUpdateSkipped();
>>      context.reloadRequired(); // or context.restartRequired();
>>      if (context.completeStep() ==
>>        OperationContext.ResultAction.ROLLBACK)
>>      {
>>        context.revertReloadRequired();
>>        // or context.revertRestartRequired();
>>      }
>> }
>
> Well in my above comment I was referring to a problem where a full
> server reload and/or restart is too aggressive (i.e. why bounce the web
> server when all you want to do is bounce a datasource). So the issue is
> that these attributes don't fit that problem.

To further clarify the reason to return the error is that the change to 
the configuration model is NOT APPLIED. If you touch the config without 
the runtime, then you are out of sync and the only reasonable action to 
take from that point on is to restart the server. In this case we are 
saying that changing an attribute could have hostile consequences 
(bouncing a connection pool therby affecting inbound transactions), and 
so we need some sort of confirmation by the admin that they really 
intend to do this.

-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat