[
https://issues.apache.org/jira/browse/QPID-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218271#comment-16218271
]
Keith Wall commented on QPID-7830:
----------------------------------
I was pondering the problem of which object(s) in the Broker would be
responsible for holding the caches of commonly used names such as destinations
or content-types. Global caches are awkward as they don't work well in the
embedded use-cases ({{String.intern}} falls into the category). I think that we
would want separate caches for different protocols - which will avoid polluting
AMQP 1.0 with AMQP 0-9..0-10 concerns.
I think we should have the VirtualHost additionally expose a set
ProtocolContext objects. ProtocolContext objects would be service loaded
using the Broker's existing pluggable pattern (factory etc). A protocol
implementations could one provide a factory if it wished. The protocol layer
itself would lookup its ProtocolContext from the VirtualHost. In a sense a
ProtocolObject would serve as a protocol specific 'singleton' scoped to the
virtualhost.
Turning back to the caching problem, in the 0-8..0-91 case,. its
ProtocolContext would expose a destination cache, content type cache etc. The
0-8 protocol layer, on the enqueue path, would consult these caches and
substitute the values from the cache if present. In the case of the
destination cache, we could make it respond to changes in the model so that
adding a queue or exchange automatically added a value to the destination cache
and removing one purged it. Perhaps for things like routingKeys, contentTypes
etc we keep a bounded LRU cache.
> Heap dominated by duplicates of common routing values / header values etc
> -------------------------------------------------------------------------
>
> Key: QPID-7830
> URL: https://issues.apache.org/jira/browse/QPID-7830
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: Future
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
