Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339378

Summary:

[server] Problem with concurrent access to WorkspaceServlet

Product:

[ECD] Orion

Reporter:

Szymon Brandys <Szymon.Brandys>

Component:

Client

Assignee:

John Arthorne <john.arthorne>

Status:

RESOLVED FIXED

QA Contact:

Severity:

critical

Priority:

CC:

bokowski, john.arthorne, malgorzata.tomczyk, simon_kaegi

Version:

0.2

Target Milestone:

0.2

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Illustration	none
Illustration 2 (many projects left after deletion)	none
Potential fix	none

Description Szymon Brandys

2011-03-09 10:51:08 EST

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.

Comment 1 Szymon Brandys

2011-03-09 10:51:46 EST

Created attachment 190768 [details]
Illustration

Comment 2 Szymon Brandys

2011-03-09 10:53:35 EST

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?

Comment 3 Szymon Brandys

2011-03-10 08:53:06 EST

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.

Comment 4 Szymon Brandys

2011-03-10 08:54:27 EST

Created attachment 190857 [details]
Illustration 2 (many projects left after deletion)

Comment 5 Boris Bokowski

2011-03-10 09:25:46 EST

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.

Comment 6 Szymon Brandys

2011-03-10 10:07:23 EST

(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.

Comment 7 John Arthorne

2011-03-10 10:44:35 EST

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.

Comment 8 John Arthorne

2011-03-10 10:50:44 EST

We should consider fixing this for M6.

Comment 9 Szymon Brandys

2011-03-10 11:41:58 EST

The fix works fine.

Comment 10 Szymon Brandys

2011-03-10 11:49:22 EST

(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.

Comment 11 John Arthorne

2011-03-10 16:48:42 EST

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.