[wildfly-dev] Proposal to read boot errors via WildFly Management APIs

[Brian Stansberry]

On 7/14/14, 9:24 AM, Brian Stansberry wrote:
> On 7/11/14, 3:02 AM, Emmanuel Hugonnet wrote:
>> So we could have something like :
>> boot-errors => {
>>    boot-error => {
>  >      operation => operationModelNode.asString();
>
> For this structure to work, it would need to be a list.
>
> boot-errors => [ {
>          operation => ...
>          ...
>      },
>      {
>          operations => ...
>      }
> ]
>
> That's a list whose elements are complex items.
>
> A hassle here is we are working to get rid of such attributes and
> convert them to child resources. To do that though we'd need
>
> 1) to have those be child resources, we'd need some id for each boot
> error. I don't really see a pure one; the best I can think of would be a
> CLI-syntax like conversion of the operation address and name.
>
> 2) we need some solid way of provide a list-like ordered semantic for
> child resources.
>
> The latter is a big issue that should not block this, so I don't think
> you should work initially toward child resources, and instead toward a
> list.

I was chatting a bit with David and he kindly pointed out that this 
doesn't have to be a resource or attribute at all; it can just be an 
operation response.

>
>  > or should we clone the whole operation modelNode ?
>
> We should make the ModelNode structure available. (Aside: we'll need to
> sanitize it for RBAC unless we make all this data security sensitive.)
>
>>        failures => {
>>     service-name => stackTrace;
>>          ....
>>        };
>>        missing-deps => list of missing dependencies as String;
>>    };
>
> You can't count on there being that kind of data for individual boot
> operations. When all the Stage.RUNTIME steps have run, that kind of data
> is gathered for the overall large set of boot ops (see [1]) but not for
> each individual boot op, which are just steps processed by the
> OperationContext. The data available for each step is just any exception
> thrown by the OperationStepHandler or any data it provides using
> OperationContext.getFailureDescription(). See [2].
>
>> };
>> returned from a read-boot-errors operation.
>>
>> I'm wondering also if we should have a "has-boot-errors" operation
>> which would be useful to just display/check the status ?
>
> What are the chances a caller would call that and then not read the
> errors if there are any? There's a bit of value (smaller payload) if
> there will be such callers.
>
> I suspect what any such caller would more likely want though would be
> some representation of the current state vs the boot state. The
> "failures => ..., missing-deps =>" data, but currently rather than what
> happened at boot.
>
>
> [1]
> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L457
>
>
> [2]
> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L613
> for the exception case and just a bit above,
> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L605
> for the getFailureDescription() case.
>
>>
>> Emmanuel
>>
>> Le 10/07/2014 16:23, Emmanuel Hugonnet a écrit :
>>> # Ability to read boot errors via  WildFly Management APIs
>>>
>>> Tracked by https://issues.jboss.org/browse/WFLY-543
>>>
>>> Use Cases
>>> ---------
>>>
>>> If a server starts but reported errors during boot, there is no way
>>> to access the error data via the Management API and users are reduced to
>>> searching the logs.
>>> This information needs to be captured and stored for later reporting.
>>> If some problem happens that gets logged at boot but somehow doesn't
>>> become visible to the management layer, that's out of scope. A problem
>>> getting logged but not becoming visible would basically mean some
>>> runtime service logged an error but the error didn't prevent the
>>> start of
>>> the service.
>>>
>>> Implementation
>>> --------------
>>> Create a new sub resource of core-service=service-container because
>>> it has the ability to dump services, thus having all the services boot
>>> errors and missing dependencies near seems like a good place.
>>> thus we would have :
>>> core-service => service-container {
>>>     boot-errors => {
>>>         failures => {
>>>             service-name => stackTrace;
>>>             ....
>>>         }
>>>         missing-deps => {
>>>             ... list of missing dependencies as String
>>>         }
>>>     }
>>> }
>>>
>>> This structure is based on the structure of the failure description
>>> returned during verification when starting a service.
>>> All these informations should be collected in the ModelControllerImpl.
>>> This resource would have restricted access of course.
>>>
>>> What do you think?
>>>
>>> Emmanuel
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat