Community
Participate
Working Groups
Steps: 1) Create some projects in the workspace (more than 1) 2) Select them all and delete using 'More actions > Delete' 3) Sometimes 'undefined' folders remain in the workspace When we do delete using 'More actions > delete', POST /workspace/ is sent per each selected folder. I think that the problem happens when multiple threads triggered by these calls try to flush changes to the preferences store. Since we are not synchronized there, Projects.prefs and Workspace.prefs become inconsistent.
Created attachment 190768 [details] Illustration
John, I wonder if synchronizing the flush is a good short term solution for M6? Do you have another idea how to address the issue for M6?
I made a short test with Gosia today and there is a problem with adding new top-level folders simultaneously by many users too. We were trying to add many projects by two logged users. And one of project was not properly saved and was shown in the navigator with 'null' name. When we try to delete all projects using 'More actions > Delete' we ended up having many not deleted or deleted partially project. See the screenshot from my screen. Gosia got something similar.
Created attachment 190857 [details] Illustration 2 (many projects left after deletion)
I am not too worried about the problem with deleting folders as long as there is an obvious way to recover, which seem to be the case. Multiple users creating folders and getting in each other's way is not good though.
(In reply to comment #5) > Multiple users creating folders and getting in each other's way is not good > though. I guess we need to postpone it to M7 since the fix is not trivial.
Created attachment 190871 [details] Potential fix This is a potential short term fix. It synchronizes doGet,doPut,doPost on WorkspaceServlet. In theory the problem is not just with concurrent writes, but also with reads during writes, since the doGet could obtain inconsistent information if called concurrently with doPost/doPut. This is a bit heavy-handed - in theory there could be multiple readers at once as long as there are no writers. However WorkspaceServlet is very low traffic in comparison with FileServlet so I don't expect noticeable user impact. The ideal fix is a more complicated refactoring of the back end data store layer so concurrently can be controlled closer to the data to ensure consistency. That would enable a higher level of concurrency.
We should consider fixing this for M6.
The fix works fine.
(In reply to comment #9) > The fix works fine. We can't see 'null' or 'undefined' projects in the workspace. When we deleted all projects in our workspaces, Workspaces.prefs did not contain any references to projects. However during one of tests not all projects from Projects.preds were removed.
I have reviewed this fix with Simon and released it for M6. I have entered bug 339602 to come up with a better solution in M7.
