RHQ/JON: Multiple Tabs and Logout

Charles Crouch ccrouch at redhat.com
Fri Aug 10 19:18:17 UTC 2012



----- Original Message -----
> 
> 
> 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 :
> 
> 
>     1. Wrap all the AsyncCallbacks (an interface) in an
>     AbstractAsyncCalllback that handles the disconnection by showing
>     the login dialog.
> 
> 
>         1. 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)
>         2. Cons: Involves many small global changes. Global search
>         and replace of AsyncCallbacks with AbstractAsyncCalllback
>     2. 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
> 
> 
>         1. Pros: Only a few classes need to be changed (although it
>         looks like LoginView also needs to be changed)
>         2. Cons: An interceptor is changing application state and
>         acting a bit like a controller
>     3. Errai Bus: This would allow Tabs(application instances) to
>     publish and subscribe to Logout events and change their state
>     accordingly
> 
> 
>         1. Pros: Clean. Client-Client or Client-Server/Server-Client
>         messaging to ensure state is reflected where it needs to be
>         2. Cons: The most work we would have to implement Errai
>     4. 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]

So is there another option? 

5) Do nothing. When we drop the portal war, and assuming we remove the servlet session/session cookie support, this problem will just disappear.

> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list