[ https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776998#comment-17776998 ]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 5:09 AM: --------------------------------------------------------------- I do not totally agree with this resolution. With the same client, ActiveMQ Classic works perfectly as it does not expect messages to be UTF8 encoded. We just switched the JMS Broker from AMQ Classic to Artemis and we are no longer able to use the system. From what I see in the Artemis code it is always expecting UTF8 messages while this does not happen in Classic version. >From my point of view *this is a regression between ActiveMQ Classic and >Artemis.* I think that the discussion from AMQCPP-692 is not relevant because if you take a look in there the proposed fix in CMS client was to use conversion to (Java modified UTF-8)[[https://stackoverflow.com/questions/7921016/what-does-it-mean-to-say-java-modified-utf-8-encoding]|https://stackoverflow.com/questions/7921016/what-does-it-mean-to-say-java-modified-utf-8-encoding] which is something else. For testing purposes I have done that conversion to the message before sending it to Artemis and it still fails. That is normal because *Java modified UTF-8* refers to something else. Looing to the ActiveMQ Classic Broker code (server side) am unable to find any similar validation for UTF8 encoding while *this is done in Artemis.* What is the rationale for the Artemis JMS Broker to perform this kind of validation? In my view this should be done only if requested (via a configuration flag or something like that). If I want to send to Artemis a message in a format I want then the server should take the message as it is. Adding conversions on top will slow down the entire process. It is not the problem of the server to ensure that the message is UTF-8 or not. It is the producer/consumer job to decide in which charset the message should be encoded/decoded. We are now forced to encode/decode all messages to UTF8 before sending them to the Artemis Broker. Regardless if we are doing this in our app or CMS client is doing it is still an extra step to perform which I found unnecessary and in addition will bring performance cost (on both client side - for encoding/decoding) and server side (the current conversions from {*}OpenWireMessageConverter{*}). was (Author: JIRAUSER300236): I do not totally agree with this resolution. With the same client, ActiveMQ Classic works perfectly as it does not expect messages to be UTF8 encoded. We just switched the JMS Broker from AMQ Classic to Artemis and we are no longer able to use the system. From what I see in the Artemis code it is always expecting UTF8 messages while this does not happen in Classic version. >From my point of view *this is a regression between ActiveMQ Classic and >Artemis.* I think that the discussion from AMQCPP-692 is not relevant because if you take a look in there the proposed fix in CMS client was to use conversion to (Java modified UTF-8)[[https://stackoverflow.com/questions/7921016/what-does-it-mean-to-say-java-modified-utf-8-encoding]|https://stackoverflow.com/questions/7921016/what-does-it-mean-to-say-java-modified-utf-8-encoding] which is something else. For testing purposes I have done that conversion to the message before sending it to Artemis and it still fails. That is normal because *Java modified UTF-8* refers to something else. Looing to the ActiveMQ Classic Broker code (server side) am unable to find any similar validation for UTF8 encoding while *this is done in Artemis.* What is the rationale for the JMS Broker to perform this kind of validation? In my view this should be done only if requested (via a configuration flag or something like that). If I want to send to Artemis a message in a format I want then the server should take the message as it is. Adding conversions on top will slow down the entire process. It is not the problem of the server to ensure that the message is UTF-8 or not. It is the producer/consumer job to decide in which charset the message should be encoded/decoded. We are now forced to encode/decode all messages to UTF8 before sending them to the Artemis Broker. Regardless if we are doing this in our app or CMS client is doing it is still an extra step to perform which I found unnecessary and in addition will bring performance cost (on both client side - for encoding/decoding) and server side (the current conversions from {*}OpenWireMessageConverter{*}). > Non-UTF-8 messages containing special characters are not supported > ------------------------------------------------------------------ > > Key: ARTEMIS-4462 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4462 > Project: ActiveMQ Artemis > Issue Type: Bug > Affects Versions: 2.30.0 > Reporter: Liviu Citu > Priority: Major > > When a text message non-UTF-8 (ISO-8859-15) containing special characters is > sent from ActiveMQ CPP client to Artemis, an exception > "java.io.UTFDataFormatException" is seen in Artemis server log. > Although the exception is thrown as a warning, the message gets rejected by > the server. > Below the Artemis server log: > > {noformat} > 2023-09-29 11:34:32,736 WARN > [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] > Errors occurred during the buffering operation > > java.io.UTFDataFormatException: null > at > org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386) > ~[activemq-client-5.17.2.jar:5.17.2] > at > org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) > ~[activemq-client-5.17.2.jar:5.17.2] > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233) > ~[artemis-openwire-protocol-2.30.0.jar:2.30.0] > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128) > ~[artemis-openwire-protocol-2.30.0.jar:2.30.0] > at > org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376) > ~[artemis-openwire-protocol-2.30.0.jar:2.30.0] > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671) > ~[artemis-openwire-protocol-2.30.0.jar:2.30.0] > at > org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769) > ~[activemq-client-5.17.2.jar:5.17.2] > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369) > ~[artemis-openwire-protocol-2.30.0.jar:2.30.0] > at > org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) > ~[artemis-commons-2.30.0.jar:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > [?:?] > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > [artemis-commons-2.30.0.jar:?] > 2023-09-29 11:34:32,753 WARN > [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] > Errors occurred during the buffering operation > org.apache.activemq.artemis.api.core.ActiveMQException: null > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674) > ~[artemis-openwire-protocol-2.30.0.jar:2.30.0] > at > org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769) > ~[activemq-client-5.17.2.jar:5.17.2] > at > org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369) > ~[artemis-openwire-protocol-2.30.0.jar:2.30.0] > at > org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32) > ~[artemis-commons-2.30.0.jar:?] > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) > ~[artemis-commons-2.30.0.jar:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > [?:?] > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > [artemis-commons-2.30.0.jar:?] > 2023-09-29 11:34:32,755 WARN > [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] > Errors occurred during the buffering operation > java.io.UTFDataFormatException: null > > {noformat} > > Just create a small test program using ActiveMQ CPP and send a message to > Artemis containing a french or german specific character. > > I have found an old discussion from ActiveMQ Community but it was focused on > ActiveMQ CPP rather on Artemis. > [https://lists.apache.org/thread/vywv1gk32mkhvj7sghnvlf7ng5zb1obp] > > This is a regression compared with ActiveMQ Classic which does not have this > issue. > Does Artemis support non-UTF-8 encoding? Do we need now to encode all > messages to UTF-8 before sending them to the server? Similarly to decode them > upon receiving? > This will cause some problems on our end because: > * we have many clients already using the ActiveMQ classic and migrating them > to Artemis will cause issues when migrating KahaDB to Artemis because all the > messages have to be encoded to UTF-8 otherwise they will not work in Artemis > * encoding/decoding every message will impact the overall performance. We > have applications handling thousands of messages every day and conversion of > these messages will increase the time spent during communication with JMS > broker > -- This message was sent by Atlassian Jira (v8.20.10#820010)