[ 
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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to