While testing oslo.messaging zmq driver, we came across with the following behavior of neutron: it sends fanout messages to the target <Target topic=q-agent-notifier-network-delete, version=1.0, fanout=True>, although there are no such services. Zmq driver uses redis as a matchmaker for coordination between rpc clients and servers, and each server registers itself in redis so that clients can find it. In our particular case redis has no records associated with the topic q-agent-notifier-network-delete, and our current behavior is to retry (20 seconds at most, 2 seconds between attempts) to get available hosts from redis, and drop the message afterwards. As a result we get failed tests. By the way, if we drop those messages immediately, everything works fine.
For example, here is the link to tempest logs: http://logs.openstack.org/44/388044/1/check/gate-tempest-neutron-dsvm-src-oslo.messaging-zmq/925c9ee/logs/screen-q-svc.txt.gz#_2016-10-18_17_39_59_053
Of course, we are currently thinking about eliminating retries to redis and simply dropping messages without recipients, but why do we need these messages in neutron? They will be dropped anyway, no matter what messaging driver is used; I guess, in rabbit the situation is even worse, because the broker may store not consumed messages in internal queues for a long time.