Task #8037 (closed)
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)
Change History (16)
Changed 12 years ago by wmoore
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 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 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...
Changed 12 years ago by wmoore
Will's data (that ben can see in other screen-shots) is in a private group.
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.
Logs from the workflow and bug described above.