[ 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