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 #12145 (closed)

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

BUG: renderings regenerated for each user

Reported by: jamoore Owned by: jamoore
Priority: blocker Milestone: 5.0.2
Component: Performance Version: 5.0.0
Keywords: thumbnails, fs Cc: java@…, jrswedlow
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description (last modified by jamoore)

Jason had the suspicion that as a group member looking at images belonging to someone else in the group thumbnails are being regenerated.

The problem:

  • If Colin is the owner of the image and Jason looks at his thumbnails. A new set of thumbnails will be generated by creating new rendering settings for Jason, We do not re-use Colin's settings (that the work I have modified in my branch)
  • To generate the rendering settings for Jason, we re-calculate the stats to determine the "best image". That will be painfully slow on this type of image.
  • The fact that it is fast the next time Jason's copy and paste the settings is mainly due to the fact that we copy (do not recalculate settings) then regenerate the jpeg.

Rendering settings should be re-used until it's necessary to generate new ones (i.e. on modification)

Change History (11)

comment:1 Changed 10 years ago by jamoore

Notes from Jason (testing over wireless network):

  • Test dataset is large CZI imported by Balaji in Basel group on demo server.
  • Is the problem thumbnailing or something else?
  • Once you have all the thumbnails rendered, if you copy and paste the rendering settings from one thumbnail, they generate quickly.
  • Moreover, for 2K x 2K image is quite acceptable if you turn on high-compression.
  • But, when first looking at the dataset on login as a member of read-annotate group and click on the dataset, something in the initial thumbnailing (queries??) is ridiculously slow. So far only on the first login when there aren't thumbnails.
  • Whatever's going on when there are no thumbnails is extremely slow.

comment:2 Changed 10 years ago by jburel

I also believe that this is probably due to the fact that we did not re-use the rendering settings from the data owner and re-calculate and regenerate thumbnails (i.e. point raised by Ilan and Douglas) I have a branch partially addressing the issue.

comment:3 Changed 10 years ago by mlinkert

Just as a sidebar, the SPIM .czi dataset from Basel likely was not imported with a build that contained this fix: https://github.com/openmicroscopy/bioformats/pull/972. The correct number of Images for that dataset is 3 (old versions picked up a few thousand), so if that's the dataset being used then it might be best to re-import or duplicate with a known-good dataset.

comment:4 Changed 10 years ago by jamoore

jburel: If you can outline how you'd reproduce in a test, that'd be appreciated.

mlinkert: certainly the case, but I think this is now a litmus test, i.e. how do we even make a dataset like this work well.

comment:5 Changed 10 years ago by jburel

This is more a story: few problems

  • Thumbnail generation:
    • If Colin is the owner of the image and Jason looks at his thumbnails. A new set of thumbnails will be generated by creating new rendering settings for Jason, We do not re-use Colin's settings (that the work I have modified in my branch)
    • To generate the rendering settings for Jason, we re-calculate the stats to determine the "best image". That will be painfully slow on this type of image.
    • The fact that it is fast the next time Jason's copy and paste the settings is mainly due to the fact that we copy (do not recalculate settings) then regenerate the jpeg.
  • We could also have plane access issue on top of it but it will be better to first look at the problems listed above so we do not waste too much time.
  • We have some tests to generate the thumbnails already.

comment:6 Changed 10 years ago by jamoore

  • Milestone changed from 5.0.2 to 5.0.3

This reworking is tentatively planned for 5.0.3 and should still be considered a 'blocker'.

comment:7 Changed 10 years ago by jamoore

  • Description modified (diff)
  • Milestone changed from 5.0.3 to 5.0.2
  • Owner cblackburn deleted
  • Summary changed from BUG: unnecessary thumbnail regeneration? to BUG: renderings regenerated for each user

Response from Jason:

Not sure that's the right answer. I'd prefer to see the first part of this--using other users thumbs-- in 5.0.2. If I read the trello cards, this has been inflated to a much larger issue, which can be divided up.


Cleaning up this ticket to represent the first part of this issue, then.

comment:9 Changed 10 years ago by jburel

  • Owner set to jamoore

assigning to josh on-going work on PR

comment:10 Changed 10 years ago by jamoore

  • Resolution set to fixed
  • Status changed from new to closed

comment:11 Changed 10 years ago by Jean-Marie Burel <j.burel@…>

(In [a8ce616d89c9eeea006e015894f261c0a52608fb/ome.git] on branch develop) Modify saveCurrentSettings behavior to create rdefs (See #12145)

After an extended discussion this morning, we decided to change
the saveCurrentSettings method to internally call saveAsNew if
the rdef does not belong to the current user.

The previous behavior was causing 5.0.1 clients to fail (4 tests
this morning were red.) The only sacrifices that had to be made
were:

  • thumbnails couldn't be generated at the same time, and
  • *intentional* saving as another user is no longer supported.
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.115114 sec.)

We're Hiring!