On 8/22/11 1:52 PM, Jason T. Greene wrote:
On 8/22/11 1:48 PM, Brian Stansberry wrote:
> 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.
>>
>
> Sure, what you propose is the right solution for only bouncing a
> datasource. But, if the operation has "impact-services" --> false,
I'm
> just saying the handler should not "return an error" (i.e. throw an
> exception or use context.getFailureDescription().set("blah blah")). It
> should properly inform the context that restart or reload is required.
That was originally what I was thinking as well. The issue is that once
you set that it's sticky right? (All further operations return
reload/restart/etc required). Then the problem becomes how do you reset
that sticky flag, and once again guarantee you are in sync.
If you bounce the ApplicationServerService (what the reload op does),
then the reload-required flag is cleared. Restart-require requires a
restart. ;)
We could also allow it to be cleared via an op, for advanced users only.
That gives me a queasy feeling. I'd be less queasy if we had an audit
log visualization tool to help that advanced user see what's transpired
since the process went into restart-required state.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat