I've come up with a patch to the amqp 1.0 driver that resets the
connection state if the pid of the current process is different from
the process that has created the connection:
https://review.openstack.org/#/c/134684/
I've managed to get this to work using rpc_workers=4 in neutron.conf,
which
Hi,
I think the main issue is the behavior of the API
of oslo-incubator/openstack/common/service.py, specially:
* ProcessLauncher.launch_service(MyService())
And then the MyService have this behavior:
class MyService:
def __init__(self):
# CODE DONE BEFORE os.fork()
def
Hi Mehdi
On Tue, Nov 25, 2014 at 5:38 AM, Mehdi Abaakouk sil...@sileht.net wrote:
Hi,
I think the main issue is the behavior of the API
of oslo-incubator/openstack/common/service.py, specially:
* ProcessLauncher.launch_service(MyService())
And then the MyService have this behavior:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I will take a look to the neutron code, if I found a rpc usage
before the os.fork().
With a basic devstack that use the ml2 plugin, I found at least two rpc
usage before the os.fork() in neutron:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mmmm... I don't think it's that clear (re: an application issue). I
mean, yes - the application is doing the os.fork() at the 'wrong'
time, but where is this made clear in the oslo.messaging API
documentation?
I think this is the real issue
Hi all,
As far as oslo.messaging is concerned, should it be possible for the
main application to safely os.fork() when there is already an active
connection to a messaging broker?
I ask because I'm hitting what appears to be fork-related issues with
the new AMQP 1.0 driver. I think the same
