[
https://issues.apache.org/jira/browse/QPID-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055895#comment-16055895
]
Keith Wall commented on QPID-7830:
----------------------------------
IIRC we removed the old AMQShortString caching as our algorithm didn't
discriminate about queue names/routing keys that related to temporary queues.
That caused our cache to appear to leak in some use cases. If we were to
reintroduce caching we'd need to deal with this case (perhaps by purging the
cache of a corresponding queue/exchange mapping when a exchange or queue is
deleted).
On the AMQP 0-8..0-91, with things like contentType, path I wonder if keeping
the BasicContentHeaderProperties#_contentType as a separate AMQShortString is
useful. Our main use case for this is routing (selector evaluation) and this
ultimately needs a {{java.lang.String}}. We only use the {{AMQShortString}}
form if the {{BasicContentHeaderProperties #_encodedForm}} has been cleared
(flow to disk). In this event, the AMQShortString form could always be
reconstructed. If we were to switch _contentType from {{AMQShortString}} to
{{String}}, we can then use {{String.intern}} (with perhaps a whitelist of our
commonly used values).
> 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
>
> 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. 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]
