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:
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.
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.
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.
This is now fixed in the trunk.