When used for store and forwarding, in some use cases the Broker's heap can become dominated by duplicates of common values such as routing information (e.g. amq.direct or an application's queue name) or common header values (e.g a application/octet-stream or an application's user id).
On the 0-8..0-91 paths, every enqueued message gets its own MessagePublishInfo referencing its own AMQShortString exchange and routing keys. For some use-cases, these are drawn from a small set. On the AMQP 1.0 path, Properties#to is an example. 0-10 is probably affected too.
This unnecessarily increases the heap requirements of the Broker.
The Broker should adopt a sensible intern/caching policy with the same policy applying regardless of whether messages follow the on-line enqueue or recovery path. Note that in AMQP 1.0, values which are Symbols have their underlying String automatically interned.