Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
4.0.0, 4.0.1, 4.0.2, 5.0.0
-
None
-
None
Description
Hello,
We have identified two (hopefully minor) bugs while using WebSockets.
1. destroying SessionScope channelToken when destroying ViewScope bean
If the user reaches the NUMBER_OF_VIEWS_IN_SESSION limit, the ViewScope bean (which holds channelTokens) is automatically destroyed (@PreDestroy). Additionally, any channelToken from the parent sessionScope is destroyed, even if it is still in use. Unfortunately, this destruction occurs after a new view is created, so the component is rendered, the WebSocket session is connected, but the channelToken in the WebsocketScopeManager is destroyed.
The solution to this issue could be simple. The destruction of the sessionScope channelToken could be left to the automatic destruction of the SessionScope. We have been testing this solution for several weeks, and it seems to be working fine.
2. using application in multiple tabs / browser windows (with same http session)
When a user is using the application in more than one tab/window within the same HTTP session, the user session channels are duplicated (with the same channelToken) and connected to the same user identification, resulting in two or more WebSocket sessions. Push messages are then sent to all tokens/sessions. So far, everything is working as expected.
However, when one of the views is destroyed (i.e., a tab/window is closed), the connected WebSocket session is also destroyed (which is expected). Unfortunately, this also will cause user connection to be removed . Since we don't track how many times the user is using this particular channelToken, the WebSocket connections in the other tabs/windows are also disrupted.
A potential solution to this issue could involve tracking the number of times the user starts using the channelToken. We could then remove the user connection after all instances of its usage are destroyed, or, alternatively, when the SessionScope object is destroyed.
Unfortunately, implementing this solution would cause a breaking change. It would involve replacing the Set holding channelTokens with a HashMap that also keeps track of the number of usages (refer to WebsocketSessionManager.java:62). Since the method getUserMap is public and may be used by others (such as ourselves, for implementing WebSocket heartbeat), they would need to update their code accordingly with the new version of MyFaces. An alternative approach could be implemented using another collection to hold the usage count of channelTokens. However, this method may not be as elegant, although it would not necessitate users to modify their applications.
So, the questions:
- which of these to implement?
- and to which version (5.0? or 4.X?)
Of course, I will prepare the changes in the form of a pull request to check the changes
Milan