[jira] [Commented] (ARTEMIS-3698) Avoid byte[] property values when converting from OpenWire

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17498905#comment-17498905 ] 

ASF subversion and git services commented on ARTEMIS-3698:
----------------------------------------------------------

Commit 40acb18f4edff27ece0217f3177efc54c42a5538 in activemq-artemis's branch refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=40acb18 ]

ARTEMIS-3698 avoid byte[] prop values when converting from OpenWire

Avoid storing the following values as byte[] for OpenWire:
 - Marshalled properties. We already store the unmarshalled properties
   so this is altogether redundant.
 - Producer ID.
 - Message ID.
 - Various destination values.

Also, eliminate the "original transaction ID" conversion code as it's
never actually set from the incoming message.


> Avoid byte[] property values when converting from OpenWire
> ----------------------------------------------------------
>
>                 Key: ARTEMIS-3698
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-3698
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Justin Bertram
>            Assignee: Justin Bertram
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Here's some example code using the Qpid JMS client:
> {code:java}
> session.createConsumer(queue).setMessageListener(message -> {
>     try {      
>         Map<String, String> headers = new TreeMap<>();
>         Enumeration<String> en = (Enumeration<String>) message.getPropertyNames();
>         while (en.hasMoreElements()) {
>             String name = en.nextElement();
>             headers.put(name, message.getStringProperty(name));
>         }
>         System.out.println(headers);
>     } catch (Exception e) {
>         e.printStackTrace();
>     }
> });
> {code}
> If an OpenWire JMS client sends messages to this queue the following exception is thrown:
> {code:java}
> javax.jms.MessageFormatException: Property __HDR_MESSAGE_ID was a org.apache.qpid.proton.amqp.Binary and cannot be read as a java.lang.String
> 	at org.apache.qpid.jms.message.JmsMessagePropertySupport.convertPropertyTo(JmsMessagePropertySupport.java:47)
> 	at org.apache.qpid.jms.message.JmsMessage.getStringProperty(JmsMessage.java:393)
> 	at com.mycompany.camel.AMQClient2.lambda$main$0(AMQClient2.java:34)
> 	at org.apache.qpid.jms.JmsMessageConsumer.deliverNextPending(JmsMessageConsumer.java:749)
> 	at org.apache.qpid.jms.JmsMessageConsumer.access$100(JmsMessageConsumer.java:58)
> 	at org.apache.qpid.jms.JmsMessageConsumer$MessageDeliverTask.run(JmsMessageConsumer.java:808)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at org.apache.qpid.jms.util.QpidJMSThreadFactory$1.run(QpidJMSThreadFactory.java:86)
> 	at java.lang.Thread.run(Thread.java:748){code}
> Despite the fact section 3.5.4 of the JMS 2 spec notes that all supported properties should be convertible to {{java.lang.String}} it's important to note that the broker supports much more than just JMS. Even the supported wire protocols used by JMS clients support much more than just JMS. Therefore, there are going to be instances where certain conversions are not possible. The JMS API has support for dealing with these instances (e.g. via the {{MessageFormatException}}) and clients should be written to deal with them. In fact, it is _critical_ for a consumer to validate a message's data and protect itself from unexpected circumstances.
> That said, it would be nice to avoid {{byte[]}} property values to improve the user experience. Therefore, I will update the broker to eliminate {{byte[]}} values when converting between properties known to be used by the OpenWire JMS client and the broker's core message format _where possible_. This will mitigate the instances of {{MessageFormatException}} observed in the code in the description, but it will not eliminate all potential instances of {{MessageFormatException}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)