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 problems have been seen with the older impl_qpid driver as well [0] Both drivers utilize a background threading.Thread that handles all async socket I/O and protocol timers. In the particular case I'm trying to debug, rpc_workers is set to 4 in neutron.conf. As far as I can tell, this causes neutron.service to os.fork() four workers, but does so after it has created a listener (and therefore a connection to the broker). This results in multiple processes all select()'ing the same set of networks sockets, and stuff breaks :( Even without the background process, wouldn't this use still result in sockets being shared across the parent/child processes? Seems dangerous. Thoughts? [0] https://bugs.launchpad.net/oslo.messaging/+bug/1330199 -- Ken Giusti (kgiu...@gmail.com) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev