datakurre
commented
11 years ago As a second thought, this X-Zope-Site-Id and only one unique queue per Zope instance, would not work when all Plone sites in the site should get the same message (e.g. would need to subscribe a fanout exchange).
Currently, consuming server is always site specific. Multiple servers may consume the same queue, but then messages from different sites would get mixed.
Currently, there must be "${site_id}" in queue name for consumer to support multiple Plone sites on the same Zope. ConsumingServer has magic to replace that with the configured site_id for consumers. It's replaced with the site_id given in consuming server -definition in buildout. In producers that must still be solved manually by adding computed routing_key-property.
https://github.com/collective/collective.zamqp/blob/master/src/collective/zamqp/server.py#L234
Example: https://github.com/datakurre/collective.zamqpdemo/blob/master/src/collective/zamqpdemo/message.py
A custom header could work as a replacement for this magic. If all (zamqp) producers would automatically add custom X-Zope-Site-Id-header, consuming server could use that when creating its ZPublisher-request. This would work automatically for Plone to Plone -messaging, but would need explicit support in non-Plone amqp-producers.
X-Zope-Site-Id would simplify server.py a lot, and would change it so that each only Zope instance would need a custom queue (and that could be defined using environment variables), but Plone-sites on the same Zope would share the queue and consumer would take care of delivering the message to the corrects site (using X-Zope-Site-Id). Also, only one consuming server per conection id would be required (now each Plone site should have its own consumign server).
On the other hand, it looks nice in the broker that each site has its own queues.