Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #12846 (closed)

Opened 9 years ago

Closed 8 years ago

Corrupted pyramid generation

Reported by: sbesson Owned by:
Priority: critical Milestone: OMERO-5.2.3
Component: Services Version: 5.1.0
Keywords: PixelData Cc: mlinkert, jamoore, pwalczysko, cblackburn
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

See https://github.com/openmicroscopy/openmicroscopy/pull/3750#issuecomment-95545237

Under some conditions, it appeared there was some corruption during the pyramid generation after importing 4kx4k JPEG files (PixelData? logs attached). This could not be reproduced on another server built from the same SHA1. Restarting the PixelData? service on the affected server fixed the issue (i.e. pyramid generated after 4kx4k import were fine.

Attachments (1)

logs_OMERO-5.1-merge-deploy_20150423.zip (3.1 MB) - added by sbesson 9 years ago.
Logs for the corrupted pyramid generation

Change History (12)

Changed 9 years ago by sbesson

Logs for the corrupted pyramid generation

comment:1 Changed 9 years ago by jamoore

  • Owner set to mlinkert

Melissa, assigning to you for your thoughts on what the cause could be. (Seb mentioned something about rendering)

comment:2 Changed 9 years ago by mlinkert

Only thing that seems suspicious is that pyramids for 4kx4k.jpg and 8kx8k.jpg are being generated at the same time. The StatsInfos? generated for the 4kx4k.jpg pyramid definitely have the wrong min/max values, so that's likely not a rendering issue. I'd guess that there is a race condition during writing and/or recompressing, but I haven't been able to reproduce the problem so far.

comment:3 Changed 9 years ago by jamoore

Petr's import of a single directory seemed to pretty reliably reproduce.

comment:4 Changed 9 years ago by mlinkert

  • Milestone changed from 5.1.2 to 5.1.3

I'm still having difficulty reproducing this locally, even doing a directory import of test_images_good/jpeg from the command line. Going to have to push to 5.1.3; if you guys have concrete steps that work and/or can put one of the broken pyramids somewhere, that'd be a big help. It might also help to know what the exact configuration of PixelData? is on the affected server.

comment:5 Changed 9 years ago by mlinkert

  • Milestone changed from 5.1.3 to 5.2.0-m1

comment:6 Changed 9 years ago by jamoore

  • Milestone changed from 5.2.0 to OMERO-5.2.0

Splitting due to milestone decoupling.

comment:7 Changed 8 years ago by jburel

  • Milestone changed from OMERO-5.2.1 to OMERO-5.2.2

Milestone OMERO-5.2.1 deleted

comment:8 Changed 8 years ago by jburel

  • Milestone changed from OMERO-5.2.2 to OMERO-5.2.1

Milestone OMERO-5.2.2 deleted

comment:9 Changed 8 years ago by mlinkert

  • Owner mlinkert deleted

Changing ownership since I don't have in-progress work or further ideas here (and not sure if it's still an issue).

comment:10 Changed 8 years ago by jburel

  • Cc cblackburn added

Colin works on CLI option to delete broken pyramid.
This was not included in 5.2.3 due to a failing test.

comment:11 Changed 8 years ago by jburel

  • Resolution set to duplicate
  • 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.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.65255 sec.)

We're Hiring!