However, even with this patch I'm seeing the following behavior:
1) reply queues are still present after the RPC has completed. This is due to the default setting for the configuration option "amqp_auto_delete" is false:
cfg.BoolOpt('amqp_auto_delete', default=False, help='Auto-delete queues in amqp.'),
So technically, this isn't a bug, but you may want to have temporary reply queues auto-deleted by default if they are created for each rpc call.
2) An rpc call on a topic is being received by all listeners instead of being load-balanced to one of the listeners. The addressing configuration for TopicConsumer will create a separate queue for each subscriber and deliver a copy to each queue. I don't believe this is the intended pattern - disregard this if I'm mistaken.
Regardless, this bug should be closed as a duplicate of 1178375. Let me know what you think of the other issues, and I can open a new bug(s)/supply patches as necessary.
Hi Mark,
Yes, I do believe that the fix for https:/ /bugs.launchpad .net/bugs/ 1178375 does in fact fix this bug.
However, even with this patch I'm seeing the following behavior:
1) reply queues are still present after the RPC has completed. This is due to the default setting for the configuration option "amqp_auto_delete" is false:
cfg. BoolOpt( 'amqp_auto_ delete' ,
default= False,
help= 'Auto-delete queues in amqp.'),
So technically, this isn't a bug, but you may want to have temporary reply queues auto-deleted by default if they are created for each rpc call.
2) An rpc call on a topic is being received by all listeners instead of being load-balanced to one of the listeners. The addressing configuration for TopicConsumer will create a separate queue for each subscriber and deliver a copy to each queue. I don't believe this is the intended pattern - disregard this if I'm mistaken.
Regardless, this bug should be closed as a duplicate of 1178375. Let me know what you think of the other issues, and I can open a new bug(s)/supply patches as necessary.
-K