problems with python and AMI

[fanson]

i write an AMI method in slice file. then i need a python client. so i do all this according to the manual, chapter 29.3.

interface Work{
["AMI"] int write(...);
}

there is a 'proxy' in the main program, and i need this proxy in my ice_responce method in class AMI_Work_writeI. (further more, i use 'sleep' in 'main' for the latency of response)

then the problem occurs, the prx->xyz(...) in my ice_response() can not work correctly. but i can see that the method xyz() is invoked, but a 'print' method after this line can not work. whether the control of the program return to 'main' when the prx->xyz(...) is invoked in ice_response()? maybe something have to do with threading?

_worker_prx = None

class AMI_Work_writeI(object):
    def __init__(self, ...):
         ...

    def ice_response(self, ...):
         global _worker_prx
         r = _worker_prx->xyz(...) // this line invoke xyz() in the server,i can see it in the server's log
         print r // i can not see the output
         ...

    def ice_exception(self,...):
         ...


__main__
    global _worker_prx
    properties = Ice.createProperties()
    properties.load(config_file)
    init_data = Ice.InitializationData()
    init_data.properties = properties
    worker = properties.getProperty("workerAddress")
    base = _communicator.stringToProxy(worker)
    _worker_prx = ...

    _worker_prx->f(...)
    cb = AMI_Worker_writeI(...)
    _worker_prx->write_async(cb,...)
    ...
    import time
    time.sleep(10)
    ...

[mes]

Hi,

The most likely reason for the hang is that your client-side thread pool does not have enough threads. As discussed in this FAQ, the client thread pool is responsible for dispatching replies (including calls to AMI callbacks) and has a default maximum size of one thread.

In your example, the AMI callback is making a nested twoway invocation. This will cause a hang when there is only one thread in the client thread pool: the nested twoway invocation blocks the calling thread, therefore no threads are available to dispatch the response to the nested invocation.

Increasing the size of the client thread pool should resolve the problem. The FAQ I mentioned earlier describes the relevant properties.

Take care,
Mark