Task #4739 (closed)
Opened 13 years ago
Closed 13 years ago
Create handler for pyramid generation
| Reported by: | jamoore | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | OMERO-Beta4.3 |
| Component: | Services | Version: | n.a. |
| Keywords: | n.a. | Cc: | |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | 2011-05-05 (11) |
Description (last modified by jmoore)
The handler should:
- have a queue for back-ground pyramid generation (done)
- have a (smaller) priority queue for interactive generation (partially done; see below)
- be able to provide a list of all pixels currently being processed (not done)
- not process any pixels currently being processed (done; see below)
- not block user threads beyond some time limit (done)
Possibility:
- recognize when too many images are being processed (e.g. a plate import) (undone)
- delete pyramids for unused images. (undone)
Change History (1)
comment:1 Changed 13 years ago by jmoore
- Description modified (diff)
- Resolution set to fixed
- Sprint set to 2011-05-05 (11)
- Status changed from new to closed
Note: See
TracTickets for help on using
tickets.
You may also have a look at Agilo extensions to the ticket.
Rather than handle the generation in a queue manner (like DeletePrx.queueDelete), pixel pyramid generation is handled in a background process more similar to indexing. The execution thread periodically queries for the last event log with the action equal to "PIXELDATA". When found, the latest event log for each user is taken and processed (which means that in some cases an eventlog for one user will be seen multiple times; it's the responsibility of the generation code to do nothing). This "per user" processing allows some users to jump ahead in the queue if another user has added many, many large images.
Since pyramids are now being created on-the-fly during import, this only pertains to older pixels or to ones added via FS.