Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » EPP » [aeri] [server] Exerimental Affected Projects per Error Report
[aeri] [server] Exerimental Affected Projects per Error Report [message #1704904] Mon, 10 August 2015 14:21
Marcel Bruch is currently offline Marcel BruchFriend
Messages: 289
Registered: July 2009
Senior Member

Since problems are an aggregation of multiple incidents (AERI-speak for error reports) it may happen that a problem does not represent a single but multiple bugs. It's currently not easy to recognize this and even hard to detect this automatically. To support the manual analysis

As of this weekend, all problem details contain a section called "Affected Projects" which gives a brief summary how often a class of a given project participated in a stack trace assigned to this problem:


If the numbers are closely together like in the above screenshot, it seems that the problem occurs in the top most project only. However, often the list of projects is much longer and the numbers are very different. Those problems likely belong to one of the following problem classes:

1. The problem describes an issue in some project X but many other projects that use that project stumble over the very same error. If that's the case, project X should fix the issue.

2. The problem is caused by clients that use the APIs of project X in a wrong way and thus cause those exceptions. Examples might be IllegalArgumentExceptions, IllegalStateExceptions, InvalidThreadAccessExceptions etc. In those cases, all clients of project X that hit this problem should reinvestigate their code and fix the problem on their side...

3. The error is more or less expected (like a ResourceException if a file wasn't found) . In that case, client's should adjust their code to either catch that exception (and do not log it as error), or do some additional checks before calling that method. Other examples might be runtime exceptions like SocketExceptions etc. Those problems may neither be a problem of project X nor of any client of X and thus should only be ignored.

We currently investigate how to make the UI more useful and to provide means how projects can get informed about especially problems of the second type. This is an ongoing process. Any suggestions how to get this right will be welcome.
Previous Topic:[aeri] [server] [client] Download aeri (client) configuration from server
Next Topic:[aeri] [poll] Should collect error reports for 3rd party plugin vendors?
Goto Forum:

Current Time: Sat Mar 02 04:58:21 GMT 2024

Powered by FUDForum. Page generated in 0.03140 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top