[
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:13 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. The message is rejected by Artemis Broker while it gets
accepted in ActiveMQ Classic.
>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/after
sending/receiving them to/from the Artemis Broker. Regardless if we are doing
this in our app or in CMS client, 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 that
exist in {*}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 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/after
sending/receiving them to/from the Artemis Broker. Regardless if we are doing
this in our app or in CMS client, 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 that
exist in {*}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)
