Task #12526 (closed)
Bug: Pyramid generation pauses
| Reported by: | wmoore | Owned by: | jamoore |
|---|---|---|---|
| Priority: | blocker | Milestone: | 5.1.0-m2 |
| Component: | Import | Version: | n.a. |
| Keywords: | n.a. | Cc: | mlinkert, mtbc, jburel, cblackburn, bpindelski, jballanco-x |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | 0.0d |
| Sprint: | n.a. |
Description
From https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=7593&p=14512
"processing of pyramid files seems to stop after a few files, unless the thumbnails are requested again.
Here is a typical case:
http://pastebin.com/3X3ySyz0
At 14:02:48 the processing stops, at 14:06 the processing continues again after I refresh the browser. This also happens for the Insight client, and there pressing the refresh button will restart pixel generation.
Change History (4)
comment:1 Changed 10 years ago by jburel
- Cc jburel added
- Milestone changed from 5.0.4 to 5.1.0-m1
comment:2 Changed 10 years ago by jamoore
- Cc cblackburn bpindelski jballanco-x added
- Milestone changed from 5.1.0-m1 to 5.1.0-m2
- Priority changed from critical to blocker
I'm currently looking into this. (Trying to find a reproducible test if anyone wants to help!) My assumption is that moving to the eventLogQueue will solve the problem until we get the full MQ solution. This could be backported to 5.0
comment:3 Changed 10 years ago by jamoore
- Resolution set to fixed
- Status changed from new to closed
PR opened: https://github.com/openmicroscopy/openmicroscopy/pull/3015
One of the two solutions will be chosen -- either the simple fix offered by Paul as the first commit or alternatively moving to EventLogQueue?.
Note: #12538 was *not* handled in that PR due to the lack of a MQ.
comment:4 Changed 10 years ago by jmoore <josh@…>
- Remaining Time set to 0
(In [bdbbb61d7314906a9d02eca8c3fce525d82ca5e1/ome.git] on branch develop) Concurrent loading of PIXELDATA EventLogs? (Fix #12526)
The EventLogQueue? was not intended to have simultaneous
threads loading logs. Instead, we now load a group of logs
in bulk and then schedule these for background processing.
The current pixel id is immediately incremented to after
the set of logs even before processing begins. Since there
was previously no transactional guarantee that a pyramid
must be created before moving on, there is no regression.
Instead, further clicks (i.e. thumbnail requests, etc.)
will have to generate a new PIXELDATA log as before if
a pyramid-creation has failed.
Moving to 5.1