Details
-
Bug
-
Resolution: Unresolved
-
None
-
None
-
High
-
Empty show more show less
Description
problem
Assume the following (yes users do that!):
- Open translate5 in three tabs.
- In two of the three tabs open a task
- then close the two tabs with the tasks, the overview tab remain
Even the tabs with the tasks are closed, the tasked remains locked and opened in translate5.
What must be known: Each Tab in translate5 makes its own connection with own connectionId to the messagebus.
The reason is a bug in the data for the garbage collector in the messagebus and a bug in the garbage collector logic on translate5 side:
Bug in messagebus
In messagebus data we store:
"connections": [ { "sessionId": "nkcvgsg5jvho3enj7e5r4tddj6d16q0n", "instance": "28a61b7947a4c26d4b69e0535942fccd", "connectionId": "7bfcbd583b0ac673a70734bf3a2f9b7e" } ], and "taskToSessions": { "{3f158f81-f9aa-46b2-b44e-4ff01bdbbb7b}": [], "{5afee082-d366-4d1f-8366-cd951ed02cc7}": [ "nkcvgsg5jvho3enj7e5r4tddj6d16q0n" ], "{f2b285bf-615e-40bd-a080-3b01e0d24605}": [ "nkcvgsg5jvho3enj7e5r4tddj6d16q0n" ] },
The data stored in taskToSessions is used internally in a lot of places in the messagebus.
map is stored just to check if the task belongs to a session (like in isSessionValidForTask), all is fine.
But if its used also to check (perhaps in messagebus garbage collection) its wrong. In the above mentioned example with closing tabs the tasks of the closed tabs will remain in the taskToSession array and is not removed. The reason is just, that the session of the task is still valid. But the connection (so in which tab the task was opened) is not stored. So therefore no garbage collection can remove the task properly from the taskToSessions list. Even if we don't use the list in that manner we should fix that, so that stalled tasks where no connections exist anymore must be removed automatically.
Bug in translate5
Basically there are two places where translate5 checks for valid sessions to connections in conjunction with job based task locking:
- \editor_Plugins_FrontEndMessageBus_Init::handleJobPut → sessionHasConnection
- \editor_Plugins_FrontEndMessageBus_Init::handleGetStalledSessions
Both places rely on the fact that there might be only one open tab per session. So again compared with the above mentioned example with tasks closed in tabs with an remaining open tab the two methods returns that the session has still a connection - what is true - and therefore the tasks are not unlocked properly / never unlocked by garbage collection (\editor_Models_TaskUserAssoc::_cleanupLocked).
Reason is that we check for the session but not for the combination session / task / connection.
solution
For 1. Bug in messagebus it must be evaluated if its really a problem in MessageBus, still the name of the list taskToSessions suggests that it is maintained properly what is not the case, so connections should be here tracked and evaluated too.
For 2. Bug in translate5 we should consider to use a identifier related to the session and connection instead to the session only. Must be updated (at least tested) what happens if connection is flapping (weak connection) - is there a new connectionId created?