Bugzilla – Full Text Bug Listing
| Summary: | Very long list of operations (tasks) I cannot remove | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Ken Walker <ken_walker> | ||||
| Component: | Client | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ahunter.eclipse, john.arthorne, simon_kaegi | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 4.0 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Some of the lines in my Users.prefs entry
B/operations///task/id/0NLs5SVnABIQAdVKRBxjbA={"expires"\:1359747125095,"Name"\:"Fetching remote\: /gitapi/remote/origin/master/file/E/org.eclipse.orion.client/"}
B/operations///task/id/4G6i1JhsABIQAe8cKm8QKQ={"expires"\:1360346260890,"Name"\:"Pulling \: /gitapi/clone/file/E/org.eclipse.orion.client/"}
B/operations///task/id/4PNmNXhWABIQAb7eJaNHTQ={"Name"\:"Fetching remote\: /gitapi/remote/origin/master/file/E/org.eclipse.orion.server/"}
B/operations///task/id/8BzViQ5gABIQAcy2J-BSTw={"expires"\:1358967434556,"Name"\:"Cloning repository undefined"}
B/operations///task/id/ABrWilVpABIQAYsHcgx0iw={"expires"\:1359987492444,"Name"\:"Fetching remote\: /gitapi/remote/origin/master/file/E/org.eclipse.orion.client/"}
B/operations///task/id/EAB44kNjABIQAbAytihmbA={"expires"\:1359320199950,"Name"\:"Cloning repository undefined"}
B/operations///task/id/EMxIQVZpABIQAYsHcgx0iw={"expires"\:1359987797669,"Name"\:"Fetching remote\: /gitapi/remote/origin/master/file/E/org.eclipse.orion.server/"}
B/operations///task/id/EPD92kNjABIQAbAytihmbA={"expires"\:1359320186277,"Name"\:"Cloning repository undefined"}
B/operations///task/id/IHn7u0ZmABIQAdAA-qw4wA={"expires"\:1359651276392,"Name"\:"Fetching remote\: /gitapi/remote/origin/master/file/E/reveal.js/"}
admin@orion:~/current/eclipse/serverworkspace/.metadata/.plugins/org.eclipse.orion.server.core/.settings> grep /operations/ Users.prefs | wc -l 566 Seems I'm not alone ;-) (In reply to comment #2) > admin@orion:~/current/eclipse/serverworkspace/.metadata/.plugins/org.eclipse. > orion.server.core/.settings> grep /operations/ Users.prefs | wc -l > > 566 > > Seems I'm not alone ;-) Hmm... the operations in Users.prefs has to be something old, because quite a while ago we created a separate file for that: Operations.prefs. The operations from Users.prefs are not displayed on this list. My guess for the reason of this problem is that the contextroot of the server was changed and now the operations under /task/id/... cannot be matched with a service that is now available under some different address (for instance /code/task/id/...). Are you looking at this? (In reply to comment #4) > Are you looking at this? For now I suggest to remove the [workspace]/.metadata/.plugins/org.eclipse.orion.server.core/.settings/Operations.prefs file on the server that should get rid of the operations that not match with the existing operationService. In M1 I'll try to implement something that will remove those operations automatically when we discover that their service is not longer available. I know how to reproduce this problem:
1. Create some tasks
2. Remove tasks
3. clear localStorage
The problem is in the preferences service. The preferences are cached in the localStorage, and as long as they are taken from there they are up to date. We synchronize them using PUT /prefs/node. This is what the doc in the server says about it:
"PUT /prefs/[path] sets all the preferences at the given path to the provided JSON object"
But in fact when we do PUT /prefs/operations with "{}" as data the preferences are not updated. It looks like there is some logic there that adds the new preferences but does not remove the old ones. This is why when we clear the localStorage and get the preferences from the server we get all the operations that where previously removed. But because they where removed we cannot find them in any service.
I think we should do something about that, because there are tons of operations run by every user every day and if they are not removed from a list the preferences files will get larger and larger.
For now I added removing the unmatched operations from the local preferences, so that when we refresh the page all the unmatched operations should be removed from the view.
John, are you still working on preference service or was it reassign to somebody new?
(In reply to comment #6) > John, are you still working on preference service or was it reassign to > somebody new? I will try to look at it this week. Anthony is also working in this area now so if he is able to take a look that would be great. I think PUT used to work it a way that is expected in this bug, removing operations that where not included in the PUT data. But this was changed. I think I remember a situation when user was using two browsers it the same time, running long running tasks on both. Doing PUT from one browser was erasing tasks started in the second browser and this was the reason somebody changed it not to remove tasks at all. But not removing tasks at all causes preferences files grow and grow, so looks like it's even worse. There is a REST API for removing single preferences: DELETE /prefs/[path]?key=[key] to delete a single preference at the given path with the given key but there is no javascript API to access it. Using that would probably solve both problems. There is a Preferences.clear() in the client API. However what it does is set the node to be {} and then perform a PUT, which would get the behaviour you describe. I think there is a missing link here - I think Preferences.clear() should result in a DELETE rather than PUT {}. Gosia can you make an attempt at fixing this? Simon is the master of the preference client stuff so adding him to validate this makes sense.
I can implement Preferences.clear() and Preferences.remove() using appropriate DELETE calls, but there is a very consistent design with scheduling preferences flush. The solution with DELETE will not be as elegant. Yes I think the same flush architecture needs to be maintained. I was thinking something like: on clear(), set the value of the node to be a special "TO DELETE" marker object (or maybe just a string). The preference implementation checks for that marker and handles it appropriately. For default preference it does nothing, for local it would clear local storage, and for server it would do HTTP DELETE. The change was bigger then I expected: operations (unlike other preferences) where not removed on PUT or DELETE. I made a change where operations are removed on DELETE, but not removed on PUT. Then I changed preference service, removing a preference does not trigger PUT, but triggers DELETE. This fixed the current issue and looks like it didn't break other functionality, but I'm still not sure if the current approach to preferences in general is OK. In preferences we have a local cache that we synchronize with server from time to time. Each time we flush the preferences we replace the remote store with out cached copy. This works fine when we use only one browser, but when we have two of them we keep overwriting the preferences set by each other. If browser 1 adds a preference "A" and then browser 2 adds a preference "B" when saving it removes the preference "A" (because it was not present in the browser 2 cache). |
Created attachment 232429 [details] Long list of operations that can't be removed I just noticed that I have a very long list of tasks that I can't remove.