[
https://issues.apache.org/jira/browse/QPID-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470114#comment-16470114
]
Keith Wall commented on QPID-8139:
----------------------------------
I don't think the patches go in the right direction. I think the changes in
responsibilities should be as follows:
# {{FilterableMessage#getMessageId}} and {{FilterableMessage#getCorrelationId}}
should return {{Object}} rather than {{String}}.
## For AMQP 1.0 simply return the corresponding message properties.
## For 0-10, getMessageId will always be a {{UUID}} or null and
getCorrelationId will be a {{UUID}}, {{String}}, or null.
## For 0-9 and Internal messages, getMessageId and getCorrelationId will always
be a {{UUID}}, {{String}}, or null.
# For AMQP 1.0 case {{JMSSelectorFilter}} will need a custom
{{JMSMessagePropertyExpression}} injected into it.
# AMQP 1.0's {{JMSMessagePropertyExpression}} must stringify the typed
{{messageId}} or {{correlationId}} according to the rules of AMQP type encoded
forms specified by the JMS Bindmap to allow a string for comparison by the
JMSMessageID or JMSCorrelationID expression. It has *no need to consider the
underlying type of the FilterableMessage*.
# For the original {{JMSMessagePropertyExpression}} it just needs to
{{String.valueOf}} the {{messageId}} or {{correlationId}} to retain existing
behaviour.
This scheme might have a performance plenty for consumers using selectors
including {{JMSMessageID}} or {{JMSCorrelationID}} predicates against AMQP 0-9
or AMQP 0-10 messages. This would be caused by the on-the-fly UUID conversion
cost. If this were found to be significant (and I actually doubt it will), we
could always optimise the {{ServerMessages}} for AMQP 0-9 and AMQP 0-10 to
have a {{Object}} messageIds and correlationIds retained from the outset. For
the AMQP 0-9 case, this would actually bring a 20 byte saving per message
saving for messages produced by the Qpid JMS AMQP 0-x client which sends a
stringified UUID as a message-id.
I don't think we should support message filtering where the producing
application choses a messageId (or correlationId) type that cannot be
represented by the AMQP protocol used by the consuming application. For
instance, messages produced by AMQP 1.0 producer using {{message-id-ulong}}
messageIds would not be selectable by a 0-10 consumer using a {{JMSMessageID}}
predicate as AMQP 0-10 cannot carry this messageId type with fidelity.
> [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or
> JMSCorrelationID expressed using the AMQP type encoded form values fail to
> select target message
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
> Reporter: Alex Rudyy
> Assignee: Alex Rudyy
> Priority: Major
> Attachments:
> 0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch,
> 0002-QPID-8139-Broker-J-AMQP-1.0-Summport-all-message-for.patch
>
>
> (2018-05-10 - rewritten JIRA title/description)
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer
> specifies a JMS message selectors including a {{JMSMessageID}} or
> {{JMSCorrelationID}} predicate, the selector can fail to find the target
> message in some circumstances. This occurs when the message producer is
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}}
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}. In the default
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in
> use. For instance, a message produced by a AMQP 0-10 producer cannot be
> selected by an consumer using a Qpid JMS Client 1.0 using a {{JMSMessageID}}
> or {{JMSCorrelationID}} predicate. This was originally highlighted by the
> following user list post:
> http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.html
> (original text of JIRA preserved below)
> JMS specification requires JMSMessageID value to start with prefix "ID:". The
> JMS client might add the prefix "ID:" to the values not starting from "ID:"
> in order to be JMS compliant. If the altered JMSMessageID value is used to
> build a selector expression like "JMSMEssageID='ID:<real id>'", the target
> message might not be found as Broker-J uses real message ids in message
> lookup.
> Potentially, filtering functionality for JMSMEssageID expression can be
> enhanced to detect the cases when the "ID:" prefix is specified in the
> selector but not included into the real message id value and find the correct
> message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
