Errai session collision with multiple tabs

[akarl]

I've got a simple chat room scenario put together where messages are sent to the server side then put into another topic where the chat clients are all listening.  I'm currently using the JBoss Comet servlet but I've found that the behavior is related to the server bus implementation and not the servlet implementation.  The behavior I'm seeing is that if I open a 2nd tab in my browser with another connection to Errai(they would share cookie space and thus session IDs) both tabs begin working erratically as far as their Errai messages are concerned.  One of the tabs is still able to send new messages but from what I can tell neither tab can receive messages.  I have a few questions.

What is the current intended behavior?  Newest connection takes over?  Older one maintains connectivity?  Both tabs work but produce multiple sockets?  Both tabs work and use the same sockets?

I understand that from a technical perspective this is a bit hairy but from a user perspective the situation is quite common. As a user I can very easily duplicate my tab which has the effect that it nukes all tabs' Errai connections (without errors!).

I took a peek at the server implementation and noticed that message queues are directly tied to session information which is where I think the problem lies.  Maybe there is something in that logic that can easily be accomplished that would at least allow one of the tabs to continue to work.

[heiko.braun]

I understand that from a technical perspective this is a bit hairy but from a user perspective the situation is quite common. As a user I can very easily duplicate my tab which has the effect that it nukes all tabs' Errai connections (without errors!).

I took a peek at the server implementation and noticed that message queues are directly tied to session information which is where I think the problem lies.  Maybe there is something in that logic that can easily be accomplished that would at least allow one of the tabs to continue to work.

Challenging situation. I bet nobody thought of this yet. However I'll ve created an issue so that it will be scheduled for the next iteration:

https://jira.jboss.org/jira/browse/ERRAI-54

[heiko.braun]

My guess: It's not the server side implementation. As you correctly noticed, the queues are associated with a HTTP session.

Two tabs, same session, same queue. Apart from synchronization issues I cannot think of anything that could go wrong with this approach.

I think it's more likely the client side bus implementation that chokes on this.

[akarl]

I dug through the client implementation briefly and didn't see an immediate problem would really cause what I'm seeing on that side.  I could maybe see some sort of cleanup of "old" subscriptions during startup but I haven't had a chance to step through the code to prove/disprove that. 

Other than that, from what I could tell the client implementation makes two simple requests using the GWT RequestBuilder then decides how to handle the responses while immediately sending out new requests so that new messages can continue.  That looks like valid use of the RequestBuilder API to me and I'd expect to see some major uproar if RequestBuilder had this constraint. 

Thanks for logging the issue, it will be interesting to see what you find.

[cbrock]

I actually have a good grasp on this problem now, and I'm actively working on fixing it.  The problem is that Errai limits the bus to one connection per session.  When a new page opens, it sends the ConnectToQueue message, replacing the old queue connection for the previous tab.   Instead, the system has to be modified to limit the connection to one connection per unique window/page.

Should hopefully have something in trunk really soon that addresses this.

[cbrock]

This is now fixed in the trunk.