search

vazexqi / CodingSpectator

Watches and analyzes code edits in the Eclipse IDE non-invasively
http://codingspectator.cs.illinois.edu
Other
20 stars 14 forks source link

Submission failed #114

Closed reprogrammer closed 13 years ago

reprogrammer commented 13 years ago

One of our users reported the following exception.

!ENTRY edu.illinois.codingspectator.monitor.core.ui 4 0 2010-11-22 22:22:36.625
!MESSAGE Failed to upload {0} data.
!STACK 0
edu.illinois.codingspectator.monitor.ui.submission.Submitter$SubmissionException: org.tmatesoft.svn.core.SVNException: svn: Commit failed (details follow):
svn: connection refused by the server
svn: OPTIONS request failed on '/svn/CodingSpectatorData/user/d2a6866d-3fcc-459c-8240-2e9d100a9f4a/1.0.0.201011111502/codingtracker'
    at edu.illinois.codingspectator.monitor.ui.submission.Submitter.submit(Submitter.java:100)
    at edu.illinois.codingspectator.monitor.ui.Uploader$1.run(Uploader.java:52)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.tmatesoft.svn.core.SVNException: svn: Commit failed (details follow):
svn: connection refused by the server
svn: OPTIONS request failed on '/svn/CodingSpectatorData/user/d2a6866d-3fcc-459c-8240-2e9d100a9f4a/1.0.0.201011111502/codingtracker'
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
    at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:899)
    at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:828)
    at edu.illinois.codingspectator.monitor.core.submission.SVNManager.doCommit(SVNManager.java:116)
    at edu.illinois.codingspectator.monitor.ui.submission.Submitter.submit(Submitter.java:97)
    ... 2 more
reprogrammer commented 13 years ago

Nick said the following:

The connection refused by server might just be a server overload http://stackoverflow.com/questions/2615652/teamcity-error-svn-connection-refused-by-the-server.

This error should go away once the server load has balanced out -- there is nothing that we can do to prevent this. The main question is: how does our tool present this error to the user? Does it fail gracefully or did it "blow up" such that [the user] could see the entire problem? Could we improve the error message? Or is this case transient enough that it shouldn't be a problem?

reprogrammer commented 13 years ago

I fixed the partial error message in f518154ab8c158778acbc556baa0bef6f8a575eb.

reprogrammer commented 13 years ago

First of all, I wonder how the user has noticed the exception. Has he discovered he error by inspecting the error log or he has just got notified by the error through a dialog. The following is the code snippet that creates the job to upload data.

Job job= new Job(MessageFormat.format(Messages.WorkbenchPreferencePage_UploadingMessage, Messages.WorkbenchPreferencePage_PluginName)) {
    @Override
    protected IStatus run(IProgressMonitor monitor) {
    try {
        submitter.submit();
        PrefsFacade.getInstance().updateLastUploadTime();
    } catch (SubmitterException exception) {
        return reportUploadFailure(exception);
    }
    return Status.OK_STATUS;
    }
};

We catch all SubmitterExceptions, log the error and return an IStatus. I assume that logging an error doesn't trigger an error dialog. If the user has noticed the error through a dialog, it must have been shown because of the way jobs communicate results to the UI in Eclipse. In this case, I don't know how we can hide the error from the user. On the other, I'm not sure if we should hide the error at all. Even though an overloaded server could well be the reason behind the upload failure in this case, one could think of other reasons such as getting disconnected from the Internet or problems such as issue #113.

vazexqi commented 13 years ago

Has he discovered he error by inspecting the error log or he has just got notified by the error through a dialog

From the contents of the entire message that was sent, I believe that this was straight from the Console of the original Eclipse instance. It was not from the Error Log in the launch Eclipse instance.

reprogrammer commented 13 years ago

This confirms that he has CodingSpectator run in the target platform.

vazexqi commented 13 years ago

I am going to close this and mark this as a transient error for the time being. If it resurfaces again we can take a deeper look into it.

reprogrammer commented 13 years ago

I reopened this issue because we haven't responded to the bug reporter yet.

Nick, could you please reply to his email and assure him that this problem has been due to a server overload? It would also be nice to point him to the user guide on how to exclude CodingSpectator from target platforms.

vazexqi commented 13 years ago

Done.