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

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

Bug: chgrp - web 'race condition'?

Reported by: wmoore Owned by: jamoore
Priority: critical Milestone: OMERO-4.4
Component: Services Version: n.a.
Keywords: n.a. Cc: atarkowska, cxallan, cneves, jburel, jamoore
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: 0.0d
Sprint: 2012-03-13 (10)

Description

Summary - with server built on 8006_chgrp_tests, using web from web_chgrp, we have basic chgrp functionality (right-click on tree, choose Move To Group, choose group, OK.)

The AJAX call loops through Image IDs, calling conn.chgrpObjects() for each. When AJAX call returns, the Images are removed from Tree.

If we refresh immediately after hitting OK (while looping through chgrp calls) this sometimes causes the Tree to display Projects, Datasets and Images from ALL groups simultaneously. Images that actually from a different group do not render (Pixels not accessible). See screen-shot! Logs attached.

Tried to create test in OmeroPy/test/integration/chgrp.py to replicate this, without success - https://github.com/will-moore/openmicroscopy/commit/47b3a3a3c27c53fe45bb1c53dc753f4843706c39

Attachments (6)

log.zip (54.1 KB) - added by wmoore 12 years ago.
Logs from the workflow and bug described above.
Screen shot 2012-02-09 at 14.31.01.png (257.0 KB) - added by wmoore 12 years ago.
screen-shot of web - all data appears in one group, thumbs broken.
Screen shot 2012-02-10 at 09.28.17.png (187.7 KB) - added by wmoore 12 years ago.
Ben - error on moving images from 'Swedlow lab' to 'many_users'
Screen shot 2012-02-10 at 09.31.46.png (177.5 KB) - added by wmoore 12 years ago.
Ben can now see will's data from test_users (Ben is not in this group)
Screen shot 2012-02-10 at 09.42.12.png (110.9 KB) - added by wmoore 12 years ago.
Will's data (that ben can see in other screen-shots) is in a private group.
log.2.zip (63.6 KB) - added by wmoore 12 years ago.
Logs for ben's move (exactly same as screenshots).

Download all attachments as: .zip

Change History (16)

Changed 12 years ago by wmoore

Logs from the workflow and bug described above.

Changed 12 years ago by wmoore

screen-shot of web - all data appears in one group, thumbs broken.

comment:1 Changed 12 years ago by jmoore

  • Cc jmoore added
  • Owner changed from jmoore to wmoore

In my chgrp branch, there is nothing server-side that would allow for loading of multiple groups. I'm just starting work on that and it hasn't been pushed anywhere. There are exceptions that would lead me to believe that {"omero.group":"-1"} has been passed, but I couldn't immediately see where that would be.

Another possibility is that its a race condition in that you load dataset A, which contains images B-Z, but by the time you start rendering images B-F, perhaps have already been chgrp'd. If so, this is similar to the delete issues #2660 and to a lesser extent #2674.

Passing back to you with a couple of questions:

  • Can you attach the web log (possibly at debug) too?
  • What steps do you think the web is taking?
  • How many groups does the data in the screenshot come from? Which group where you moving the image to/from?
  • Can you think of a race condition in which something is changing the current group context (perhaps due to the chgrp call) while loading is taking place?

Changed 12 years ago by wmoore

Ben - error on moving images from 'Swedlow lab' to 'many_users'

Changed 12 years ago by wmoore

Ben can now see will's data from test_users (Ben is not in this group)

comment:2 Changed 12 years ago by wmoore

Once the bug above has been reproduced, I can see ALL the data from ALL of my groups in my P/D/I tree. Not just the images I was moving or the groups I was moving between. If I switch user, I can see ALL of their data from ALL of their groups, even see data from groups that I am not a member of. The bug and behavior is the same for Admins and non-Admins.

In the screen-shots above, a non-admin 'ben' has caused the bug by moving images between his two groups. He can now see will's data, even from 'test_users' group. This is a private group that he is not a member of.

Reproducing this bug does not involve switching groups on the web. All I have to do is refresh the web page immediately after submitting a number of images to chgrp.

I thought the web logs would be in the zip I sent you, but it seems they didn't get created again when I stopped server, removed logs, started again and reproduced bug. I'll try again...

Last edited 12 years ago by wmoore (previous) (diff)

Changed 12 years ago by wmoore

Will's data (that ben can see in other screen-shots) is in a private group.

Changed 12 years ago by wmoore

Logs for ben's move (exactly same as screenshots).

comment:3 Changed 12 years ago by wmoore

  • Owner changed from wmoore to jmoore

Forgot to switch this back to you after my last updates....

comment:4 Changed 12 years ago by jburel

  • Sprint changed from 2012-02-14 (8) to 2012-02-28 (9)

Moved from sprint 2012-02-14 (8)

comment:5 Changed 12 years ago by wmoore

With "merge-green" on gretzky I can reproduce this bug with merge-green looking like this:

*   2885ada (HEAD, team/merge-green, merge-green) Merge remote-tracking branch 'gh/sprint9-web-backlog' into merge-green
|\  
| * 163444d (gh/sprint9-web-backlog, sprint9-web-backlog) Fixed is_valid() bug in UsersForm. Closes #8114
| * 166a36d fixing users select box, close #8110
* | 4ffc10d (8052_web_chgrp) Improved UI and Activities for web chgrp
* | 6dadaea Basic working chgrp in web.
* | be5a9c1 (gh/8006_chgrp_OmeroPy, 8006_chgrp_OmeroPy) Gateway chgrp asynchronous test
* | dc08821 Blitz chgrpObject() returns prx without waiting
* | 0aa92b2 Adding chgrp test - Image in 2 Datasets
* | ba02d1c Adding chgrp gatewaytests for D/I and P/D/I
* | ea09a8b Blitz Gateway Test for chgrp - Image. See #8014
* | 27e2b9a Blitz Gateway createGroup() method.
* | 0fd25a9 chgrpObject() added to Blitz Gateway. See #8014
* | b038a64 Chgrp PDI test
* | e00d04d Complete chgrp tests for Image
* | 7d7d7e4 Group util methods in integration/library.py
* | f5b0b5e First OmeroPy chgrp test. See #8006
* |   55b44ea (ola/7993_transition, 7993_transition) Merge remote-tracking branch 'origin/develop' into 7993_transition

comment:6 Changed 12 years ago by jburel

  • Sprint changed from 2012-02-28 (9) to 2012-03-13 (10)

Moved from sprint 2012-02-28 (9)

comment:7 Changed 12 years ago by jmoore

  • Status changed from new to accepted

comment:8 Changed 12 years ago by jmoore

  • Remaining Time set to 0.1

Fix uploaded to my 3529-callcontext branch (https://github.com/joshmoore/openmicroscopy/tree/3529-callcontext):

commit ecf24f49519268d83e4a9f359f5cf993bca3b7ad
Author: jmoore <josh@glencoesoftware.com>
Date:   Thu Mar 1 15:00:01 2012 +0100

    Make ShareBean.setShareId public (See #2219, #3529, Fix #8037)
    
    The use of shareId==-1 was intended only for session-wide
    activities. The use via HandleI and ChgrpI led to the data
    leakage outlined by Will (#8037).
    
    This commits makes use of the omero.group facilities added
    as part of #3529.

This can be merged into origin/develop along with Will's work in order to test.

comment:9 Changed 12 years ago by jmoore

  • Remaining Time changed from 0.1 to 0
  • Resolution set to fixed
  • Status changed from accepted to closed

Hopefully to be merged today.

comment:10 Changed 12 years ago by jmoore <josh@…>

(In [ecf24f49519268d83e4a9f359f5cf993bca3b7ad/ome.git] on branch develop) Make ShareBean?.setShareId public (See #2219, #3529, Fix #8037)

The use of shareId==-1 was intended only for session-wide
activities. The use via HandleI and ChgrpI led to the data
leakage outlined by Will (#8037).

This commits makes use of the omero.group facilities added
as part of #3529.

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.70973 sec.)

We're Hiring!