[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627470#comment-16627470
]
Rob Godfrey commented on QPID-8245:
-----------------------------------
[~alex.rufous] So the majority of the patches aren't that different I think. I
got rid of all the getXXX methods and just kept
{code:java}
public Object get()
{
...
}
{code}
The other thing is I don't think there is any need for two different
implementations in the broker - we only need the version that stores the byte
buffer. When creating a new FieldTable we pass in a map and it is converted to
the binary encoding. In decoding my approach (which I hadn't finished) was
slightly different. I would hold a _properties map, only containing the values
for keys that have been specifically requested. I wouldn't bother keeping a
record of the position I've decoded "up to"... In the case where a message has
150 properties, and a filter on the property that happens to be the 135th...
there's really no point remembering all those other decoded values.
Anyway, I had a quick scan of your patches and they look reasonable
> [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-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]
