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

[Brian Stansberry]

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.

 > 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