[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627710#comment-16627710
]
Alex Rudyy commented on QPID-8245:
----------------------------------
Rob,
Thanks for the review comments. I attached patch
0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch removing getXXX
methods and replacing calls to getXXX with {{Object get()}}. The patch replaces
previous patch 0005-QPID-8245 splitting FieldTable into 2 implementations.
I think that putting the decoded properties into {{_properties}} Map should
reduce the decoding attempts. For example, in the case where a message has 150
properties, and a filter has expression for property #135 followed by property
#100, decoding field table and storing properties up to #135 would save us the
following decoding round. Has I missed anything?
Keeping a record of the position would prevent decoding of already decoded
property. Potentially, the position can be saved directly in QBB by invocation
of mark()/reset() but it makes code more convoluted. To be fair, I do not like
the fact that more memory is consumed by every message due to creation
LinkedHashMap and storing the position. I think the better approach would be
creation of headers FieldTable lazily in {{BasicContentHeaderProperties}}. That
might save some heap space when routing messages into destinations bound
without filters.
I ran the performance tests with my changes, and to my surprise the performance
on machine with a lot of memory and CPUs became worse, in spite of the fact
that profiler (instrumentation and sampling) gives better performance metrics
for message routing and enqueuing. I cannot really explain such results at the
moment. Perhaps, synchronization of methods in {{FieldTable}} and
{{BasicContentHeaderProperties}} plays some role here. The performance of
{{0-10}} is twice better than 0-9 for the same test
> [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand
> --------------------------------------------------------------
>
> Key: QPID-8245
> URL: https://issues.apache.org/jira/browse/QPID-8245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Affects Versions: qpid-java-broker-7.1.0
> Reporter: Alex Rudyy
> Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch,
> 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch,
> 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch,
> 0004-QPID-8245-Decode-field-table-properties-when-require.patch,
> 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch,
> 0005-QPID-8245-Split-field-table-into-2-implementations.patch
>
>
> At the moment all field table properties are decoded when decode
> functionality is invoked. For use cases when only some of the field table
> properties are queried, the decoding functionality can be changed to stop
> decoding on getting the requested property. Potentially, such approach can
> improve the performance of routing transient messages when destinations are
> bound to the routing exchange using selector filters. As filter expression
> contains only some properties, the decoding of message headers can be stopped
> on getting all fields specified in selector expression.
> The idea is illustrated by Rob Godfrey on
> [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
