BUG: Cannot change active group while working in application

[atarkowska]

Cannot change active group. Perhaps server could handle that better to be sure nothing stops user to switch between groups.

Fri, 07 May 2010 11:58:18 wrapper      ERROR    Traceback (most recent call last):
  File "/Users/ola/Dev/omero/components/tools/OmeroWeb/omeroweb/extlib/gateway.py", line 126, in changeActiveGroup
    self.c.sf.setSecurityContext(omero.model.ExperimenterGroupI(gid, False))
  File "/Users/ola/Dev/omero/dist/lib/python/omero_API_ice.py", line 197, in setSecurityContext
    return _M_omero.api.ServiceFactory._op_setSecurityContext.invoke(self, ((obj, ), _ctx))
SecurityViolation: exception ::omero::SecurityViolation
{
    serverStackTrace = ome.conditions.SecurityViolation: SecurityContext change cancelled:
Client 61001815-3907-48a7-8b43-24dcfd9fee5e has active stateful services: count=27

	at ome.services.sessions.events.ChangeSecurityContextEvent.throwIfCancelled(ChangeSecurityContextEvent.java:61)
	at ome.services.sessions.SessionManagerImpl.setSecurityContext(SessionManagerImpl.java:1091)
	at ome.services.blitz.impl.ServiceFactoryI.setSecurityContext(ServiceFactoryI.java:312)
	at omero.api._ServiceFactoryDisp.___setSecurityContext(_ServiceFactoryDisp.java:385)
	at omero.api._ServiceFactoryDisp.__dispatch(_ServiceFactoryDisp.java:1347)
	at IceInternal.Incoming.invoke(Incoming.java:159)
	at Ice.ConnectionI.invokeAll(ConnectionI.java:2037)
	at Ice.ConnectionI.message(ConnectionI.java:972)
	at IceInternal.ThreadPool.run(ThreadPool.java:577)
	at IceInternal.ThreadPool.access$100(ThreadPool.java:12)
	at IceInternal.ThreadPool$EventHandlerThread.run(ThreadPool.java:971)

    serverExceptionClass = ome.conditions.SecurityViolation
    message = SecurityContext change cancelled:
Client 61001815-3907-48a7-8b43-24dcfd9fee5e has active stateful services: count=27

}

[jmoore]

#2196 specified the work for this. In discussion with Chris, it was decided that if there is an active stateful service, it will most likely not handle the security context change well. Ola, I'm passing this back to you. We'll need to decide what semantics we can allow, and once we've done that, we'll need tests.

[atarkowska]

In my opinion there should be a specific method to change active group on the server side which handle specific use case.

[jmoore]

I'm happy to be proved wrong, but I think that the logic of how/when/which stateful services should be closed belongs in the client. You almost certainly want to ask the user "did you remember you were doing X? Save or don't save?" If you know that none of that is the case, then we can off a closeAllStatefulServices() which does the same as closeSession(), but as I mentioned on Skype, I consider having stateful services just hanging around a bug.

[jmoore]

It's probably not necessary (nor wise) to be changing this at the moment. Let's re-evaluate later in the 4.2 series.

[jmoore]

(In [7817]) Adding omero.client.getStatefulServices() to all OmeroClients for better test cleanup. (See #1736, #2339)

[jmoore]

(In [8402]) Modifying setSecurityContext test to pass (See #2339, #3189)

Two services were not closed and therefore the exception
is expected. See comments in test for more information.

[jmoore]

This has come up again on the forums. ​https://www.openmicroscopy.org/community/viewtopic.php?f=6&t=951 At least as a part of the method gateway.changeActiveGroup() we should decide how to handle this and state it in the docs. Is the client required to loop through the contents of getStatefulServices -- I'm certainly fine with that, but we need to be careful that these services aren't being left open by us (e.g. some method that opens a search internally and leaves it handling)

Passing to Will for his thoughts since he hasn't been CC'd on this yet.

[cneves]

All the services created using the connection wrappers are available under conn._proxies. We might want to iterate them and close as needed on the changeActiveGroup call. Alternatively setting self._proxies = NoProxies() will mark all services to be garbage collected, but this may not be enough.

[jmoore]

Cool, thanks Carlos. For me the key is: do we know that the user/client understands that all extant stateful services are about to be closed? I assume this is handled at the web level at the moment, but will need to be clear at the gateway level as well.

[cneves]

Probably a flag on changeActiveGroup called {{ forceStatefulClose }} or something alike, and proper capture of the exceptions thrown if one fails to do so (basically catch SecurityException?) and re-raise of an exception (maybe the same) with a comment "Stateful services open, please close them prior to changing groups or call with forceStatefulClose=True" ?

[wmoore]

I think that Carlos' proposal for the Gateway behavior sounds fine.

For the web, I think I'd be happy to force closure of all stateful services with the exception of any that have jobs running (E.g. Delete or Scripts). Currently, our only handle of jobs in the web is the request.sessioncallback?. I guess we could check this before forcing changeGroup, but it would be nicer if we could ask the server "are there any jobs running now?"

[wmoore]

Josh - returning to you: This sounding reasonable now?

[jmoore]

Will, the exception you mention is the important point. We can certainly add another method to return just the "important" stateful services (though I still think that's very hard to specify from the server-side), but for the moment it's pretty straight-forward to check the open stateful services and check their type: if it's a DeleteHandle or a ScriptProcessor then you'll have to handle it. But that just brings us back to the question of what to do, and the forceStatefulClose won't help.

Any chance of you guys discussing that this afternoon?

[jmoore]

Passing to jean-marie for doc update after conversation (​https://www.openmicroscopy.org/site/community/minutes/conference-calls/2012/2012-01-10-tuesday-meeting)

[jburel]

Currently in insight, users can only change group when on-going tasks are completed e.g. import.
When the user changes group, all services e.g. re, pixels store, etc., are closed. Prior to that the user is notified and has the option to save changes. The UI is totally refreshed and data from new group are loaded.

I am going to investigate a possible new workflow for change group where a user will have the ability to have 2 groups displayed at the same and moving between them w/o having to shutdown services.

[jburel]

Passing to Ola for web addition if required, otherwise it can be closed

[atarkowska]

Webclient simply create new session when user wants to switch to the new group. Old session should be killed by the server when is no longer used. There are various solution already offered in the web to move data between groups. Currently tree filter data for P/D/I, but I do not see any problem with loading Group/User?/P/D/I instead. It is only important to know how to modify session be able to get those data from the server. Is just one/two more levels - very easy to support. Closing ticket.