Task #10474 (closed)
Opened 11 years ago
Closed 9 years ago
Bug: webgateway deleteObjects() method does not update status
| Reported by: | aknab | Owned by: | mtbcarroll |
|---|---|---|---|
| Priority: | critical | Milestone: | 5.1.0 |
| Component: | General | Version: | 4.4.8 |
| Keywords: | n.a. | Cc: | java@… |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | n.a. |
Description
When deleting OriginalFile? objects using the webgateway's deleteObjects method, the status object returned by calling handle.getStatus() has a property 'steps' that does not get updated during the delete process. It remains at zero and will jump to the total number of objects once deletion is complete.
The desired behavior is for status to indicate how far the deletion process has progressed.
The following unit test demonstrates the problem.
https://github.com/knabar/openmicroscopy/commit/bc2edfc12ccd6429c9cf5b79da16a1f1a473307f
Branch: https://github.com/knabar/openmicroscopy/commits/delete-status-test
Change History (16)
comment:1 Changed 11 years ago by jmoore
- Milestone set to OMERO-4.5
- Priority changed from minor to critical
- Sprint set to Bugs Fixing
- Summary changed from webgateway deleteObjects() method does not update status to Bug: webgateway deleteObjects() method does not update status
- Type changed from Bug to Task
comment:2 Changed 11 years ago by jmoore
- Component set to General
comment:3 Changed 11 years ago by jmoore
comment:4 Changed 11 years ago by jburel
- Sprint changed from Bugs Fixing to 2013-04-09 (7))
Moved from sprint Bugs Fixing
comment:5 Changed 11 years ago by jburel
- Sprint changed from 2013-04-09 (7)) to 2013-05-07 (8)
Moved from sprint 2013-04-09 (7))
comment:6 Changed 11 years ago by jburel
- Sprint changed from 2013-05-07 (8) to Blocker 4.4.9 (1)
Moved from sprint 2013-05-07 (8)
comment:7 Changed 11 years ago by jamoore
- Cc java@… added
- Version set to 4.4.8
This should be a fairly straight-forward matter to investigate. (Omitting any API changes for making it simpler to check the current step).
comment:8 Changed 11 years ago by mtbcarroll
- Owner changed from jamoore to mtbcarroll
comment:9 Changed 11 years ago by mtbcarroll
- Status changed from new to accepted
comment:10 Changed 11 years ago by mtbcarroll
- Milestone changed from OMERO-4.4.9 to OMERO-4.4.x
- Owner changed from mtbcarroll to jamoore
- Sprint Blocker 4.4.9 (1) deleted
pushing out of 4.4.9
comment:11 Changed 10 years ago by jamoore
- Milestone changed from OMERO-4.4.x to 5.0.0-beta3
comment:12 Changed 9 years ago by mtbcarroll
Opened https://github.com/openmicroscopy/openmicroscopy/pull/3566 for current step number.
comment:14 Changed 9 years ago by mtbcarroll
I haven't touched the "concurrency issues in Java" bit and don't have any immediate clues about that. Maybe it doesn't now happen though? Can close this and open a new ticket if there is some outstanding issue.
comment:15 Changed 9 years ago by jamoore
Mark: if you saw no signs of the previous issue, then I'd agree, let's close and re-open if it re-arises. (Unless this becomes a "write more tests" ticket and is pushed)
comment:16 Changed 9 years ago by mtbcarroll
- Resolution set to fixed
- Status changed from accepted to closed
Yes, in my testing I didn't see anything odd in the client's view of the handle's status.
Andreas: status.steps is the total number of steps, and so once initialization has passed, it will be the total number, not the current number. However, the zeroes you are seeing are likely caused by concurrency issues in Java, and I'll look into fixing that. Other than the size of the status.stepStartTimes array, there isn't a simple, non-callback way to get access to the current step number at the moment, which is something that will need to be looked into.