[
https://issues.apache.org/jira/browse/ARTEMIS-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509022#comment-17509022
]
Justin Bertram commented on ARTEMIS-3698:
-----------------------------------------
bq. I'm running on the same journal as the previous broker, meaning that some
messages where received before this change. Could that be the problem?
Yes.
bq. Can the warning be safely ignored?
The error isn't fatal, but the messages won't have the message ID and producer
ID which they had originally. It's likely you can safely ignore that, but I
don't know your use-case so I can't say for sure.
> 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: 20m
> 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)
