BUG: No Processor Available

[wmoore]

Trying to run script like
​http://trac.openmicroscopy.org.uk/omero/browser/trunk/components/blitz/resources/omero/api/IScript.ice#L40

Will commit test below...

wjm:OmeroPy will$ PYTHONPATH=$PYTHONPATH:.:test:build/lib ICE_CONFIG=/Users/will/Documents/workspace/Omero/etc/ice.config python test/integration/scripts.py TestScripts.testRunScript
E
======================================================================
ERROR: testRunScript (__main__.TestScripts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/integration/scripts.py", line 84, in testRunScript
    proc = scriptService.runScript(scriptId, map, None)
  File "/Users/will/Documents/workspace/Omero/dist/lib/python/omero_api_IScript_ice.py", line 149, in runScript
    return _M_omero.api.IScript._op_runScript.invoke(self, ((scriptID, inputs, waitSecs), _ctx))
ResourceError: exception ::omero::ResourceError
{
    serverStackTrace = 
    serverExceptionClass = 
    message = No processor available.
}

----------------------------------------------------------------------
Ran 1 test in 18.871s

[wmoore]

(In [6803]) Failing test. See #2304.

[jmoore]

This seems to be caused for the most part by internal use of proxies:

// In some servant
InteractiveProcessorPrx prx = factory.sharedResources().acquireProcessor(...);
prx.execute(...);

both the call "acquireProcessor" and "execute" are remote calls, since we currently have collocation optimization turned off (though even then it may consume threads).

We may have to make an explicit rule to not use internal proxy calls if at all possible (when calling to OmeroPy, for example, it can't be avoided.)

[jmoore]

(In [6811]) see #2304 - Removing remote calls from ScriptProcessI

[jmoore]

(In [6814]) Various fixes to have scripting running again. See #1341, #2304, #2261, #2253

[jmoore]

r6811 looked to have cleaned up the ResourceErrors, but a subsequent test ran into the same issue. The cause is still unknown.

[jmoore]

(In [6833]) see #2304 - Probably cause is SQL locking

[jmoore]

Primary issue turns out to be a call to IceMapper.map on a session-connected object, leading to large scale DB loading (in validateScript). A secondary issue which permitted the restarts to sometimes clear up the issue was that processors were not recalling session.sharedResources().addProcessor() on subsequent sessions.

[jmoore]

(In [6925]) see #2304 - adding processors on newly created sessions

[jmoore]

(In [6926]) fix #2304 - moving IceMapper outside of session