we ran wsgi compliant web server which calls Stream UDF lua function. Everything was working well with gevent.wsgi, but recently we are moving to Gunicorn Wsgi.
Unfornutelly with this setup Stream UDF call get stuck. Function doesn’t return any value and blockes forever.
I think the issue is due to the Python client multiple threads; when Gunicorn, or anything else , forks the Python interpreter it copies memory into a new interpreter process, but does not copy running threads.
So when query.results() gets called: the new interpreter processor waits to acquire a lock so it can do work safely; but this will never happen because the thread which is holding that lock is not running in the new interpeter’s process. So the lock remains locked forever, and the interpreter hangs.
I think you can get around this if you make sure to create and connect the Aerospike Client after the fork.
So in Gunicorn, I imagine this would be creating the client in the post_fork hook: Settings — Gunicorn 20.1.0 documentation
we are running python 3.6 and the latest aerospike client 3.4.2.
We dont have any other Stream UDF so far, but classic key-based query (client.get(key)) works well.
Anyway, it seems that you are right with the locking problem. We postpone connect method and UDF STream function doesn’t block anymore.