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