Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] Mars M5 packages
Thanks Chuck,

On 06 Feb 2015, at 20:58, Chuck Bridgham <cbridgha@xxxxxxxxxx> wrote:

Thanks Marcel, 

The exceptions I hit were definitely real problems in the code, although they were logged exceptions with no harmful consequence.  So users had been unaware.    We should be cleaning these up, but just commenting on the experience. 

I'm actually very interested in leveraging these reports.   My main concern with all of these additions is a change in behavior for the many thousands of satisfied users that will encounter new dialogs and wizards we have opted in for them.  We should try to keep these to a minimum, unless they choose to participate.

FWIW, some short replies to shed some light on the current implementation and future plans:

* a user first has to enable the error reporting before getting the “An Error Was Logged” dialogs. If she does not wish to participate, she will never see the error dialog.
* the error reporter remembers which errors it sent before. If an error is logged the second time, no dialog will show up.
* if two errors share the exact same stacktrace but have a different messages, you will get the dialog. However, you can configure the error reporter to “skip similar errors" in the future, i.e., ignore same errors with different messages (see [1] for more details and screenshots).
* Bug 442719 speaks about a server-managed ignore list. Plans are to create this list based on the committers input in the web ui. E.g., if a problem is marked as an ordinary log message or muted (see screenshot below), we may use that input to build said ignore list “automatically". This is something I’d like to add in M7 and enable during the RCs.



Also, if a common log has been identified - is there a way to scan the server before opening up the dialog?  I realize this is an expensive network transaction, and could impact the responsiveness of the IDE.

* As mentioned above we send errors only once per user.
* The server-side ignore list will do it’s best to further reduce the network traffic. It will be downloaded on startup (and only if new).
* With M6 the data collection can be disabled remotely, i.e., the client checks whether the service is available before sending data and remembers that value for some time.
* I’m not sure to which extent sending a gzipped error report in a background job will affect the responsiveness of the IDE. In addition there will only be one upload job at a time. I assume (but might be proved wrong) that the cost of sending that data is neglectable.



Thanks,
Marcel



Back to the top