BUG: Changing group thrown exception

[atarkowska]

Exception Type: 	AttributeError
Exception Value: 	

'NoneType' object has no attribute 'id'

Exception Location: 	/Users/ola/Dev/omero/components/tools/OmeroWeb/omeroweb/../omeroweb/webclient/views.py in change_active_group, line 419

[jburel]

Moved from sprint 2011-06-02 (13)

[wmoore]

I've seen this once but NOT reproducible.

[jmoore]

The only use of ".id" I see in that method is:

def change_active_group(request, **kwargs):
    ... 
    blitz = settings.SERVER_LIST.get(pk=server) 
    request.session['server'] = blitz.id

which sounds oddly like something that Carlos was looking into, where the server configuration could get lost. I'm passing to Carlos so he can check if this is related.

[cneves]

Unrelated to the issue itself: the use of change_active_group is redundant with the following methods on the connection object, as defined in omero.gateway;

    def setGroupNameForSession (self, group):
        """
        Looks up the group by name, then delegates to L{setGroupForSession}, returning the result
        
        @param group:       Group name
        @type group:        String
        @return:            True if group set successfully
        @rtype:             Boolean
        """

    def setGroupForSession (self, groupid):
        """
        Sets the security context of this connection to the specified group
        
        @param groupid:     The ID of the group to switch to
        @type groupid:      Long
        @rtype:             Boolean
        @return:            True if the group was switched successfully
        """

    def revertGroupForSession (self):
        """ Switches the group to the previous group """

[cneves]

Replying to jmoore:

which sounds oddly like something that Carlos was looking into, where the server configuration could get lost. I'm passing to Carlos so he can check if this is related.

Indeed, given the multithreaded access to the worker, there is always a slight chance that the sqlite db is locked for reading, which would certainly result in errors like this one. I couldn't find anything else that could obviously trigger this issue, but I'll wait for tomorrow's test of the thread locked worker before closing this ticker.

[atarkowska]

Replying to cneves-x:

Replying to jmoore:

which sounds oddly like something that Carlos was looking into, where the server configuration could get lost. I'm passing to Carlos so he can check if this is related.

Indeed, given the multithreaded access to the worker, there is always a slight chance that the sqlite db is locked for reading, which would certainly result in errors like this one. I couldn't find anything else that could obviously trigger this issue, but I'll wait for tomorrow's test of the thread locked worker before closing this ticker.

We no longer use sqlite db (was redundant over a year ago) and there is not chance to lock it ;-). The issue might come from the fact that either session didn't store server id or was removed for some reason

    server = request.session.get('server')
    ...
       
    webgateway_views._session_logout(request, request.session.get('server'))
    
    blitz = settings.SERVER_LIST.get(pk=server) 

[atarkowska]

I can;t reproduce it.