qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message
Date Thu, 10 May 2018 09:04:00 GMT

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


Mime
View raw message