Bugzilla – Full Text Bug Listing
| Summary: | [progress service] Client should remove tasks when read and no longer needed. | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Malgorzata Janczarska <malgorzata.tomczyk> |
| Component: | Client | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Szymon.Brandys |
| Version: | unspecified | ||
| Target Milestone: | 0.4 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Malgorzata Janczarska
Could you elaborate the idea? I would expect to have a param for the task to remove all task related data on the server when the task is finished and the result is returned. I guess that this bug is about something else. I was suggesting that client after handling the task result could do DELETE on the task.
> I would expect to have a param for the task to
> remove all task related data on the server when the task is finished and the
> result is returned.
This would be perfect. This is something I'd like to achieve. The only problem I have here is that when does server know we can remove this task and its data? The result needs to be red by interested client first, we have to wait for this.
Removing task on first GET would be a very bad idea from the RESTful point of view.
I realized that depending on the client side to provide a knowledge should the task be removed is hard if we want to keep is transparent weather the operation is run as a task or not. First of all client doesn't really schedule the task: he just requests an operation that ends up as a task because is lasted too long. Second of all the use of progress service allows client side to be unaware if the operation ended as task or not, also knowledge about the taskId is lost on the progressService level. Currently I see 3 situations that need for sure need tasks to be cleaned: 1. Git log, and possibly other GET operations, they should be removed straight away after they're displayed 2. "Auth fail" error that are handled by displaying the credentials prompt and after re-sending the request the "Auth fail" error should be removed 3. Very old operations: like one month, no body really cares that 1 month or 2 weeks ago he made a clone. This operations not only take place on the server but decrease scalability on the task service. We should have some kind of a timeout. For (1) I think we could leave the knowledge up to the server, probably server should return some kind of a flag on the task indicated that is was indepotent or not. Indepotent tasks should be removed by progress service shortly after they are read and displayed as finished. For (3) we can also implement it on server. (2) is a specific case and I really don't know how to generalize it. I don't really know if we will have any other operations of this kind. Maybe just a custom solution for this one will do the trick, having few "expected" errors in the operations log looks really badly. My problem was, I had lots of 404 errors in the console. Whatever you think is good to get rid of it would be welcome. (In reply to comment #4) > My problem was, I had lots of 404 errors in the console. Whatever you think is > good to get rid of it would be welcome. Ignore the last comment please. Wrong bug. (In reply to comment #3) > 1. Git log, and possibly other GET operations, they should be removed straight away after they're displayed One done. > 2. "Auth fail" error that are handled by displaying the credentials prompt and > after re-sending the request the "Auth fail" error should be removed Done. Operations are removed whenever git operation is renewed with new credentials. > 3. Very old operations: like one month, no body really cares that 1 month or 2 > weeks ago he made a clone. This operations not only take place on the server but > decrease scalability on the task service. We should have some kind of a timeout. Only reasonable thing was to check for old operations on server start. This was done by the way of checking for running operations that weren't finished because of server restart. I think it is good for now. I think the number of unnecessary operations was decreased enough to close this bug. |