Proposal to read boot errors via WildFly Management APIs

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to read boot errors via WildFly Management APIs

Emmanuel Hugonnet
# 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (550 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Stan Silvert
You can read the error messages with the read-log-file operation.  Does that not meet the requirements?

/subsystem=logging/:read-log-file(name=server.log,lines=500,skip=0,tail=false)

On 7/10/2014 10:23 AM, Emmanuel Hugonnet wrote:
# 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Brian Stansberry
In reply to this post by Emmanuel Hugonnet
What's reported there is a subset of possible management errors during
boot; i.e. not all errors that can occur during execution of the boot
ops need to manifest themselves as service failures or missing dependencies.

I also think there needs to be more context; i.e. what management
operation was being invoked when a problem occurred. We get lots of
complaints about how users can't understand what our service names mean
when they try and understand failures. Showing address data doesn't
solve that completely, but it certainly helps.

On 7/10/14, 9:23 AM, Emmanuel Hugonnet wrote:

> # 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

David Lloyd-2
In reply to this post by Emmanuel Hugonnet
On 07/10/2014 09:23 AM, Emmanuel Hugonnet wrote:

> # 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.

I think this makes more sense as an operation than a resource - i.e.
"give me all the boot errors" => "okay, here you go as a big list".

The rule of thumb (for me) is that a resource typically corresponds to
one or more services.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Heiko Braun
In reply to this post by Emmanuel Hugonnet
+1

Especially useful within a manged domain




> Am 10.07.2014 um 16:23 schrieb Emmanuel Hugonnet <[hidden email]>:
>
> Ability to read boot errors via  WildFly Management APIs
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Heiko Braun
What nonsense post of mine.


> Am 11.07.2014 um 08:34 schrieb Heiko Braun <[hidden email]>:
>
> Especially useful within a manged domain
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Emmanuel Hugonnet
In reply to this post by Emmanuel Hugonnet
So we could have something like :
boot-errors => {
  boot-error => {
    operation => operationModelNode.asString(); or should we clone the whole operation modelNode ?
      failures => {
        service-name => stackTrace;
        ....
      };
      missing-deps => list of missing dependencies as String;
  };
};
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 ?

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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (550 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

kkhan

On 11 Jul 2014, at 09:02, Emmanuel Hugonnet <[hidden email]> wrote:

> So we could have something like :
> boot-errors => {
>  boot-error => {
>    operation => operationModelNode.asString(); or should we clone the whole operation modelNode ?
I think it is better to use it as the operation ModelNode

>      failures => {
> service-name => stackTrace;
>        ....
>      };
>      missing-deps => list of missing dependencies as String;
>  };
> };
> 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 ?
>
> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Scott Marlow
In reply to this post by Emmanuel Hugonnet
On 07/10/2014 10:23 AM, Emmanuel Hugonnet wrote:

> # 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?

Should the application server terminate (with a failure code) when
errors occur during boot?  This might make it more obvious that the
server didn't start correctly and that logs should be scanned for the
cause.

>
> Emmanuel
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Brian Stansberry
On 7/11/14, 8:21 AM, Scott Marlow wrote:
> On 07/10/2014 10:23 AM, Emmanuel Hugonnet wrote:
>
> Should the application server terminate (with a failure code) when
> errors occur during boot?  This might make it more obvious that the
> server didn't start correctly and that logs should be scanned for the
> cause.
>

At some point we'll offer an option for that, but I don't see it
becoming our only mode of operation.

Personally, I don't like having the default being continuing to run
"normally."

Brainstorming a bit, I could also see having the server switch into
admin-only mode instead of terminating.


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Brian Stansberry
In reply to this post by Emmanuel Hugonnet
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

James Perkins
In reply to this post by Emmanuel Hugonnet
I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html.

On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote:
# 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Emmanuel Hugonnet
Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example.
Emmanuel

Le 15/07/2014 02:23, James R. Perkins a écrit :

> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or
> possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html.
>
> On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote:
>> # 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> James R. Perkins
> JBoss by Red Hat
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (550 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Stan Silvert
On 7/17/2014 6:28 AM, Emmanuel Hugonnet wrote:
Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example.
Emmanuel
"some service might log errors"?

Do we have a solid use case?  I'd like to understand what this is for.


Le 15/07/2014 02:23, James R. Perkins a écrit :
I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or
possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html.

On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote:
# 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
-- 
James R. Perkins
JBoss by Red Hat


      

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Stan Silvert
On 7/17/2014 8:44 AM, Stan Silvert wrote:
On 7/17/2014 6:28 AM, Emmanuel Hugonnet wrote:
Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example.
Emmanuel
"some service might log errors"?

Do we have a solid use case?  I'd like to understand what this is for.

I guess I should be more clear about what I don't understand.  I take it that this proposal wants to gather the boot errors so they can be accessed by some other process?  What would the process be able to do with the information?

If the purpose is to let users see the errors then that is already achieved by reading the log.  So I take it that the use cases are not user-centric?


Le 15/07/2014 02:23, James R. Perkins a écrit :
I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or
possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html.

On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote:
# 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
-- 
James R. Perkins
JBoss by Red Hat



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

James Perkins
In reply to this post by Emmanuel Hugonnet

On 07/17/2014 03:28 AM, Emmanuel Hugonnet wrote:
> Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example.
> Emmanuel
Excellent. Just wanted to make sure we weren't going to duplicate work :)

>
> Le 15/07/2014 02:23, James R. Perkins a écrit :
>> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or
>> possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html.
>>
>> On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote:
>>> # 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>

--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to read boot errors via WildFly Management APIs

Emmanuel Hugonnet
In reply to this post by Stan Silvert
Well, the users could quickly check the errors with a script instead of searching through the logs or even looking 'manually' in the log viewer.
Of course they could already be doing something with the logs, this aims to be easier to access / use.

Le 17/07/2014 15:01, Stan Silvert a écrit :

> On 7/17/2014 8:44 AM, Stan Silvert wrote:
>> On 7/17/2014 6:28 AM, Emmanuel Hugonnet wrote:
>>> Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example.
>>> Emmanuel
>> "some service might log errors"?
>>
>> Do we have a solid use case?  I'd like to understand what this is for.
>
> I guess I should be more clear about what I don't understand.  I take it that this proposal wants to gather the boot errors so they can be
> accessed by some other process?  What would the process be able to do with the information?
>
> If the purpose is to let users see the errors then that is already achieved by reading the log.  So I take it that the use cases are not
> user-centric?
>
>>
>>> Le 15/07/2014 02:23, James R. Perkins a écrit :
>>>> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or
>>>> possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html.
>>>>
>>>> On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote:
>>>>> # 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> --
>>>> James R. Perkins
>>>> JBoss by Red Hat
>>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (550 bytes) Download Attachment