[
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)
