RHQ/JON: Multiple Tabs and Logout

mike thompson mithomps at redhat.com
Fri Aug 10 17:27:12 UTC 2012


Your Feedback is appreciated:

The Problem:

Two tabs (A and B) share a single servlet session. Tab A performs a Logout. Tab B still thinks it is in a good state and tries to rpc to the server where the servlet session is invalidated and error message is received by the user (a nasty InvocationException with a stacktrace).

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=816598

How should we handle multiple tabs? The non-technical stuff. We have all been on sites that don't handle multiple tabs.

Solutions:
Wrap all the AsyncCallbacks (an interface) in an AbstractAsyncCalllback that handles the disconnection by showing the login dialog.
Pros: clean, detection handled in one place (where it should be in a callback handler). We can now have default error handling and DRY up some of the code required to show messages . Aids in consistency as we can just tell the onFailure() to show a message and optionally a severity level (or whatever else)
Cons: Involves many small global changes. Global search and replace of AsyncCallbacks with AbstractAsyncCalllback
Use the TrackingRemoteServiceProxy and TrackingRequestCallback as an interceptor for the rpc requests so that we can gracefully handle the InvocationException with providing a login dialog box
Pros: Only a few classes need to be changed (although it looks like LoginView also needs to be changed)
Cons: An interceptor is changing application state and acting a bit like a controller
Errai Bus: This would allow Tabs(application instances) to publish and subscribe to Logout events and change their state accordingly
Pros: Clean. Client-Client or Client-Server/Server-Client messaging to ensure state is reflected where it needs to be
Cons: The most work we would have to implement Errai
Or don’t allow a second login


Ideally, we would not have a servlet session as it legacy architecture (a throwback to the seam/JSF stuff). All the services would be stateless and the smartGWT app has all the state. This gives us a scalable (load balanced) and redundant service layer. Not having the servlet session would eliminate the need for a session cookie. And we would avoid all the issues with cookies such as multiple user logins (User1:TabA / User2:TabB) and multiple hosts (hosta.redhat.com and hostb.redhat.com share the same cookie for the domain redhat.com). [The portal.war albatross is becoming heavier as time goes on]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20120810/522b7d54/attachment-0001.html>


More information about the rhq-devel mailing list