You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Justin Bertram (Jira)" <ji...@apache.org> on 2022/02/26 04:52:00 UTC
[jira] [Updated] (ARTEMIS-3698) Avoid byte[] property values when converting from OpenWire
[ https://issues.apache.org/jira/browse/ARTEMIS-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Justin Bertram updated ARTEMIS-3698:
------------------------------------
Description:
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}}.
> 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)