Hi all,
I've been testing mules a lot lately. I started off with programmed mules,
but eventually discovered that mules work in the traditional fork-and-exec
method, and this occurs after the master has fully loaded, at the same time
that workers are forked.
This messed up some pieces of my application in the mules because they were
using postfork hooks that fired too early (at the fork from master, before
exec). I got that straightened out but this led me to wonder whether I
could just use unprogrammed mules instead.
With programmed mules we're just loading the same application as the master
process, without the wsgi stack on top. It'd be quicker and simpler if our
mules could just be forks from the master. The documentation says that
unprogrammed mules are "signal only", however.
Turns out, most things seem to work, except that message passing has
intermittent problems and signals are not always passed. For example, I can
send mule messages, but occasionally they fail (I believe this is being
raised in a worker):
File
"/home/nate/work/galaxy/.venv/local/lib/python2.7/site-packages/uwsgidecorators.py",
line 194, in mule_msg_dispatcher
msg = pickle.loads(message)
cPickle.UnpicklingError: invalid load key, '{'.
Where '{' is the first character of the message string.
Signals do typically propagate to mules with --py-call-osafterfork set, but
I have found that sometimes they don't (if the mules are blocked on
mule/farm_get_msg??) unless I send a mule message from a worker after
signalling, regardless of whether the mule actually seems to receive the
message (which it does not always do).
tl;dr, should I keep trying to debug this (I think maybe it's because of
the way I'm handling things postfork) or should I not expect unprogrammed
mules to work with messages?
Thanks,
--nate
_______________________________________________
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
