Bug 910718 - Console should react properly to loss of connection
Summary: Console should react properly to loss of connection
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Console
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER2
: EAP 6.1.1
Assignee: baranowb
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 975403
TreeView+ depends on / blocked
 
Reported: 2013-02-13 11:29 UTC by Jakub Cechacek
Modified: 2015-02-01 23:00 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The Web Management Interface used in Red Hat JBoss Enterprise Application Platform 6 is a Google Web Toolkit (GWT) application and, as such, uses GWT deferred binding to load application components on demand. In some cases the deferred loading failed and would freeze the overall application with no indication about the source of the problem. In this release, proper error handling for the deferred binding has been introduced. Now, in the event of a problem when loading application compoments on demand, the exceptions are handled gracefully and the web console remains accessible.
Clone Of:
Environment:
Last Closed: 2013-09-16 20:24:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker AS7-6759 0 Major Resolved Console should react properly to loss of connection 2014-04-28 09:54:50 UTC

Description Jakub Cechacek 2013-02-13 11:29:35 UTC
Currently lose of connection with EAP instance repeatedly leads to "Unknown error" followed by a console freeze. I believe this behavior is not right -- or at least it doesn't explain what happened. 
 
Steps to Reproduce:
1. Start EAP
2. navigate to console (e.g. http://localhost:9990/)
3. Kill the EAP 
  
Actual results: Bunch of "Unknown Errors" will pop-up followed by client side freeze

Expected results: Some appropriate error message (e.g. "Connection Error", "Connection lost,...) followed (if possible) by some more reasonable action (permanently displayed error info?)

Comment 1 baranowb 2013-03-14 15:31:04 UTC
This actually is a bit complicated issue. Ive managed to talk briefly to hpehl about it.


GWT has AsyncCallback interace. It is used in console to handle certain interactions. Currently its a bit inconsitient.
Some classes implement interface as inner class, ie:
ServerGroupPresenter{
public void onSaveCopy(final ServerGroupRecord orig, final ServerGroupRecord newGroup) {
        window.hide();

        final ModelNode operation = new ModelNode();
        operation.get(OP).set(READ_RESOURCE_OPERATION);
        operation.get(ADDRESS).add("server-group", orig.getName());
        operation.get(RECURSIVE).set(true);

        dispatcher.execute(new DMRAction(operation, false), new AsyncCallback<DMRResponse>() {
            @Override
            public void onFailure(Throwable caught) {
                Console.error("Failed to read server-group: "+orig.getName(), caught.getMessage());
            }

            @Override
            public void onSuccess(DMRResponse result) {

                ModelNode response = result.get();

                if(response.isFailure())
                {
                    Console.error("Failed to read server-group: "+orig.getName(), response.getFailureDescription());
                }
                else
                {
                   .....
                }

            }

        });
    }
}


NOTE: 


public static void info(String message) {
        getMessageCenter().notify(
                new Message(message, Message.Severity.Info)
        );
    }



While other classes use: public abstract class SimpleCallback<T> implements AsyncCallback<T> {

    @Override
    public void onFailure(Throwable caught) {
        Log.error("Unknown error", caught);
        Diagnostics.logError("dmr-invocation", System.currentTimeMillis(), caught.getMessage());
        Console.getMessageCenter().notify(
                new Message("Unknown error", caught.getMessage(), Message.Severity.Error)
        );
    }
}

This is the main reason of "Uknown error" seen as concise message . This is a bit inconsistent. Notice that Console.xxxx method invokes new Message(String x,Severity y) while SimpleCallback does it a bit differently.

There are two cases here, when message is displayed - 
1. when concise message - shown as bar in console, is initialized to Exception.getMessage(). The getMessage() may contain various content - whole dump, stack trace, localized content (UIConstanget.*) and whatever is present there( I did not review each callback trace, so I may be off in some of them)
2. "Uknown Error" string is passed as concise message, while full message is initialized to #1 - the getMessage() from exception.


Sollution:

Create base exception class whith additional field to carry localized content - displayed as concise message, while Exception.message will carry everything else.
This will fix the "Uknown Error" not only for 500, but all other failure cases.

Comment 2 Heiko Braun 2013-06-04 07:16:38 UTC
should be fixed in 1.5.2 already

Comment 3 Jakub Cechacek 2013-07-03 11:01:36 UTC
Verified 6.1.1.ER2

Comment 4 Scott Mumford 2013-08-14 23:18:46 UTC
Added a draft Release Note to the Doc Text field above. Please review for technical accuracy.

Comment 5 Scott Mumford 2013-08-15 00:50:38 UTC
Resetting needinfo as it was cancelled accidentally in last action.
See comment 4.

Comment 6 Scott Mumford 2013-08-23 05:07:23 UTC
Resetting NEEDINFO flag. Again.

Please review the Release Note text above and validate for technical accuracy.

Comment 7 Heiko Braun 2013-08-23 05:56:34 UTC
The release notes text doesn't make sense. I would change it to:

Cause
The Web Management Interface is a Google Web Toolkit (GWT) application and, as such, use GWT deferred binding to load application compoments on demand. In some cases the deffered loading did fail and such freeze the overall application.

Consequence
In some cases the web console did freeze.
These symptoms gave no indication about the source of the problem. 

Fix 
Proper error handling for the deffered binding was introdcued.

Result
Even in case of a problem when loading application compoments on demand, the exception are handled gracefully and web console remains accessible.

Comment 8 baranowb 2013-08-23 06:10:32 UTC
Seems like Heiko provided review.

Comment 9 Scott Mumford 2013-08-26 01:07:43 UTC
Have updated Release Note text based on Heiko's input and marked for inclusion in the 6.1.1 Release Notes document.


Note You need to log in before you can comment on or make changes to this bug.