[jira] [Created] (AMQCPP-752) CMS API compatibility with 6.x brokers
Liviu Citu created AMQCPP-752: - Summary: CMS API compatibility with 6.x brokers Key: AMQCPP-752 URL: https://issues.apache.org/jira/browse/AMQCPP-752 Project: ActiveMQ C++ Client Issue Type: Improvement Reporter: Liviu Citu Assignee: Timothy A. Bish Hello, The latest version of CMS API contains the following node: *NOTE:* Compatible with ActiveMQ Broker versions in the 4.X and 5.X family [https://activemq.apache.org/components/cms/download/395-release] As we have now 6.X brokers, is this API compatible with them? If so can you please update the documentation to reflect that? Thank you -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQCPP-751) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/AMQCPP-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778652#comment-17778652
]
Liviu Citu commented on AMQCPP-751:
---
Hi Tim, Robbie,
Are you aware of other available C++ Openwire client that is up to date with
Security & C++ standards?
We are currently using CMS API but we might try to switch to something else if
possible.
Thank you,
- Liviu
> Non-UTF-8 messages containing special characters are not supported
> --
>
> Key: AMQCPP-751
> URL: https://issues.apache.org/jira/browse/AMQCPP-751
> Project: ActiveMQ C++ Client
> Issue Type: Bug
>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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1598#comment-1598
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/20/23 7:33 AM:
---
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That
doesn't mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works. I am not sure
why/when the server will have to decode something and even if it does it should
use the default charset (if I want to use UTF8 then I will specify that in the
java options or there should be a configured parameter somewhere).
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expecting messages to be UTF8 encoded then this should be
clearly stipulated in the official documentation because right now there is no
reference for it. Actually there is no encoding reference at all in the
documentation.
I am also for using UTF8 but right now calling an extra function on all our
applications for UTF8 encoding is a change in functionality which might have
performance cost.
Perhaps a message property might need to be decoded on the server side and has
to be UTF8 which I can agree but not the message text (which can be a very
large string and encoding/decoding takes CPU time).
was (Author: JIRAUSER300236):
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That
doesn't mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works. I am not sure
why/when the server will have to decode something and even if it does it should
use the default charset (if I want to use UTF8 then I will specify that in the
java options or there should be a configured parameter somewhere).
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expecting messages to be UTF8 encoded then this should be
clearly stipulated in the official documentation because right now there is no
reference for it. Actually there is no encoding reference at all in the
documentation.
I am also for using UTF8 but right now calling an extra function on all our
applications for UTF8 encoding is a change in functionality which might have
performance cost.
Perhaps a message property might need to be decoded which I can agree but not
the message text (can be a very large string and encoding/decoding takes CPU
time).
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1598#comment-1598
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/20/23 7:29 AM:
---
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That
doesn't mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works. I am not sure
why/when the server will have to decode something and even if it does it should
use the default charset (if I want to use UTF8 then I will specify that in the
java options or there should be a configured parameter somewhere).
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expecting messages to be UTF8 encoded then this should be
clearly stipulated in the official documentation because right now there is no
reference for it. Actually there is no encoding reference at all in the
documentation.
I am also for using UTF8 but right now calling an extra function on all our
applications for UTF8 encoding is a change in functionality which might have
performance cost.
Perhaps a message property might need to be decoded which I can agree but not
the message text (can be a very large string and encoding/decoding takes CPU
time).
was (Author: JIRAUSER300236):
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expecting messages to be UTF8 encoded then this should be
clearly stipulated in the official documentation because right now there is no
reference for it. Actually there is no reference at all in the documentation
related to encoding.
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1598#comment-1598
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/20/23 7:18 AM:
---
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expecting messages to be UTF8 encoded then this should be
clearly stipulated in the official documentation because right now there is no
reference for it. Actually there is no reference at all in the documentation
related to encoding.
was (Author: JIRAUSER300236):
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expecting messages to be UTF8 encoding then this should be
clearly stipulated in the official documentation because right now there is no
reference for it. There is no reference in the documentation related to
encoding.
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1598#comment-1598
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/20/23 7:17 AM:
---
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expecting messages to be UTF8 encoding then this should be
clearly stipulated in the official documentation because right now there is no
reference for it. There is no reference in the documentation related to
encoding.
was (Author: JIRAUSER300236):
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expected messages to be UTF8 encoding then this should be
clearly stipulated in the official documentation because right now there is no
reference for it.
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1598#comment-1598
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/20/23 7:17 AM:
---
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591).
If Artemis is always expected messages to be UTF8 encoding then this should be
clearly stipulated in the official documentation because right now there is no
reference for it.
was (Author: JIRAUSER300236):
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591.
> 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
[jira] [Reopened] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liviu Citu reopened ARTEMIS-4462:
-
Reopened as I do not agree with the statement:
_its probable you aren't seeing an issue on 5.x broker because you aren't
currently doing anything that needs it to decode the content there. That doesnt
mean_ _the content is valid._
I have sent a message with special French character (non UTF8 encoding) and it
is accepted by 5.x broker. The content is valid and it works.
Note that I am running 5.x broker in Windows with French regional settings. The
same character works also if I am using US regional settings (the encoding is
the same ISO-88591.
> 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
>
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1559#comment-1559
]
Liviu Citu commented on ARTEMIS-4462:
-
We are using ActiveMQ 5.x Broker with CMS API in our financial software for
more than 10y now (before we used CORBA Orbix). Many of our clients (banks in
top 10 tier) that are using our software have non-ASCII strings (for instance
German/French letters) without any issues and we are *NOT* encoding the
messages in UTF-8 in broker communication.
In the past years we have many requests from our clients to support failover
and also upgrade to Artemis. Hence we are going into this direction. Our
software base code is C++ so we cannot simply switch to Java client. This is
out of discussion because we cannot simply rewrite a software that was millions
on lines of code and many functionalities (integrations with other software,
etc).
Now there are two distinct issues that pop out from our discussion and I would
like not to mix them:
* first issue in CMS API that is not doing the UTF8 conversion before sending
the messages to the broker. I am not sure that it is supposed to do it anyway.
It has some APIs ({*}activemq::util::MarshallingSupport::asciiToModifiedUtf8
and activemq::util::MarshallingSupport::modifiedUtf8ToAscii){*} but they are
NOT doing the correct UTF8 conversion. These APIs are for *Java Modified UTF8*
which is not the same as standard UTF8 that Artemis broker expects. I have done
a simple test but calling *asciiToModifiedUtf8 /* *modifiedUtf8ToAscii* on a
string containing *é* and{*}:{*}
** *asciiToModifiedUtf8* doesn't do anything. the input string does not get
modified{*}{*}
** calling *modifiedUtf8ToAscii* after *asciiToModifiedUtf8* throws
*UTFDataFormatException.* This cannot be right, these functions should work in
pair regardless what kind of conversion they are doing.{*}{*}
I managed to make the message work by using ICU converter. The character in
question has 2 bytes in UTF8 as it should whereas on the client machine using
ISO-88591 encoding has 1 byte.
* second issue (the one I have reported here) is that Artemis Broker is
expecting UTF-8 payload while 5.x broker doesn't. We may have used it wrongly
for so many years but it worked. We know that Java client is doing the
conversion to UTF-8 as we have some Java apps which send message to the Broker
and C++ CMS that is processing them and we had to convert in C++ (only for that
specific app) the message back from UTF8 but t{*}his is Java client who is
doing the conversion{*}. Classic Broker does not expect UTF-8 payload since we
are sending it that way from CMS API for so long and it works.
We cannot simply change the messages from text to bytes because there may be
other (custom client applications) that are processing those messages and they
may expect them to be text.
What we have temporary done was to convert the message to UTF8 before sending
them to Artemis and it works. However this might impact the performance of the
system. We haven't yet officially released our software version supporting
Artemis broker but we want to be prepared to provide explanations to our
clients why this extra step (UTF-8 encoding/decoding) is needed. Clients might
argue that since their Artemis broker is installed on a machine using the same
locale/encoding as all their clients then it does not make sense to perform
extra encoding/decoding. The server should take the messages as they are
received.
> 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)
>
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1144#comment-1144
]
Liviu Citu commented on ARTEMIS-4462:
-
Not sure why I do not see those exceptions in my 5.x broker console then. What
I can tell is that I see them in my Artemis broker console.
I will run some more tests on 5.x broker and come back.
PS. I see that your links are from *activemq-client.* I suppose those classes
are also used by the broker (server) side. I will check that by debugging the
server.
Please note that as I stated at the beginning our client is not Java but CMS.
So those classes are not used by client side.
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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:
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 5:12 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/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
exists 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 sending them to
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 exists 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:
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 5:12 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/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
exists 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 5:10 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 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 exists 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 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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]
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
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 5:08 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]
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{*}).
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]
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.
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 5:01 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]
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.
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.
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 5:00 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 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.
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 am unable to find any similar validation of UTF8 messages in the ActiveMQ
Classic server base code. What function/class from ActiveMQ Classic code is
doing the same validation/conversion as Artemis server code is doing?
> 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)
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 4:12 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 am unable to find any similar validation of UTF8 messages in the ActiveMQ
Classic server base code. What function/class from ActiveMQ Classic code is
doing the same validation/conversion as Artemis server code is doing?
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 am unable to find any similar validation of UTF8 messages in the ActiveMQ
Classic server base code. What function/class from ActiveMQ Classic code is
doing the same as Artemis server code is doing?
> 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)
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 4:11 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 am unable to find any similar validation of UTF8 messages in the ActiveMQ
Classic server base code. What function/class from ActiveMQ Classic code is
doing the same as Artemis server code is doing?
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 am unable to find any similar validation of UTF8 messages in the ActiveMQ
Classic server base code. What function/class is doing the same as Artemis is
doing?
> 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
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 4:10 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 am unable to find any similar validation of UTF8 messages in the ActiveMQ
Classic server base code. What function/class is doing the same as Artemis is
doing?
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.*
Please confirm that ActiveMQ Classic is handling the messages in the same
manner as Artemis as I am unable to find any validation of UTF8 messages in the
ActiveMQ Classic server base code.
> 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
>
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 4:08 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.*
Please confirm that ActiveMQ Classic is handling the messages in the same
manner as Artemis as I am unable to find any validation of UTF8 messages in the
ActiveMQ Classic server base code.
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.*
Please perform an indication that ActiveMQ Classic is handling the messages in
the same manner as Artemis as I am unable to find this in the ActiveMQ Classic
server base code.
> 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
[jira] [Comment Edited] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu edited comment on ARTEMIS-4462 at 10/19/23 4:07 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.*
Please perform an indication that ActiveMQ Classic is handling the messages in
the same manner as Artemis as I am unable to find this in the ActiveMQ Classic
server base code.
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.
>From my point of view this is a regression between ActiveMQ Classic and
>Artemis.
Please perform an indication that *ActiveMQ* Classic is handling the messages
in the same manner as Artemis as I am unable to find this in the ActiveMQ
Classic server base code.
> 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
>
[jira] [Commented] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776998#comment-17776998
]
Liviu Citu commented on ARTEMIS-4462:
-
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.
>From my point of view this is a regression between ActiveMQ Classic and
>Artemis.
Please perform an indication that *ActiveMQ* Classic is handling the messages
in the same manner as Artemis as I am unable to find this in the ActiveMQ
Classic server base code.
> 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)
>
[jira] [Reopened] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[
https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liviu Citu reopened ARTEMIS-4462:
-
> 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
>
[jira] [Updated] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[ https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Citu updated ARTEMIS-4462: Description: 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: _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_
[jira] [Updated] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
[ https://issues.apache.org/jira/browse/ARTEMIS-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Citu updated ARTEMIS-4462: Description: 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: _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_
[jira] [Created] (ARTEMIS-4462) Non-UTF-8 messages containing special characters are not supported
Liviu Citu created ARTEMIS-4462: --- Summary: 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 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. See email from ActiveMQ Community in attachment for more details. Below the Artemis server log: _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
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[ https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723982#comment-17723982 ] Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 5:32 PM: -- > This is a weakness in the application design which will lead to the same > problems with duplicate messages as you have when a broker failure causes the > consumer-group relationship to change. I am not seeing it as a weakness rather than an incomplete solution as we might still have duplicated messages (as you said) which in the end will fail during database import (see below). However, I think it is still better to have a local cache than nothing. There might be some other complex solutions when load balancing is used but this local cache will (still) help to reduce unnecessary database insert failures. > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, I have seen Kafka having idempotent consumers. Never used it though. was (Author: JIRAUSER300236): > This is a weakness in the application design which will lead to the same > problems with duplicate messages as you have when a broker failure causes the > consumer-group relationship to change. I am not seeing it as a weakness rather than an incomplete solution as we might still have duplicated messages (as you said) which in the end will fail during database import (see below). However, in the context of load balancing I think it is still better to have a local cache than nothing. There might be some other complex solutions indeed but this local cache will (still) help especially for those applications which do not have load balancing. > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, I have seen Kafka having idempotent consumers. Never used it though. > Message Group does not replicate properly during failover > - > > Key: ARTEMIS-4276 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4276 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > We are currently migrating our software from Classic to Artemis and we plan > to use failover functionality. > We were using message group functionality by setting *JMSXGroupID* and this > was working as expected. However after failover switch I noticed that > messages are sent to wrong consumers. > Our gateway/interface application is actually a collection of servers: > * gateway adapter server: receives messages from an external systems and > puts them on a specific/virtual topic > * gateway loader server (can be balanced): picks up the messages from the > topic and do processing > * gateway fail queue: monitors all messages that failed processing and has a > functionality of resubmitting the message (users will correct the processing > errors and then resubmit transaction) > *JMSXGroupID* is used to ensure that during message resubmit the same > consumer/loader is processing the message as it was originally processed. > However, if the message resubmit is happening during failover switch we have > noticed that the message is not sent to the right consumer as it should. > Basically the first available consumer is used which is not what we want. > I have searched
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[ https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723982#comment-17723982 ] Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 5:32 PM: -- > This is a weakness in the application design which will lead to the same > problems with duplicate messages as you have when a broker failure causes the > consumer-group relationship to change. I am not seeing it as a weakness rather than an incomplete solution as we might still have duplicated messages (as you said) which in the end will fail during database import (see below). However, I think it is still better to have a local cache than nothing. There might be some other complex solutions when load balancing is used but this local cache will (still) help to reduce unnecessary database insert failures. > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, I have seen Kafka having idempotent consumers. Never used them though. was (Author: JIRAUSER300236): > This is a weakness in the application design which will lead to the same > problems with duplicate messages as you have when a broker failure causes the > consumer-group relationship to change. I am not seeing it as a weakness rather than an incomplete solution as we might still have duplicated messages (as you said) which in the end will fail during database import (see below). However, I think it is still better to have a local cache than nothing. There might be some other complex solutions when load balancing is used but this local cache will (still) help to reduce unnecessary database insert failures. > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, I have seen Kafka having idempotent consumers. Never used it though. > Message Group does not replicate properly during failover > - > > Key: ARTEMIS-4276 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4276 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > We are currently migrating our software from Classic to Artemis and we plan > to use failover functionality. > We were using message group functionality by setting *JMSXGroupID* and this > was working as expected. However after failover switch I noticed that > messages are sent to wrong consumers. > Our gateway/interface application is actually a collection of servers: > * gateway adapter server: receives messages from an external systems and > puts them on a specific/virtual topic > * gateway loader server (can be balanced): picks up the messages from the > topic and do processing > * gateway fail queue: monitors all messages that failed processing and has a > functionality of resubmitting the message (users will correct the processing > errors and then resubmit transaction) > *JMSXGroupID* is used to ensure that during message resubmit the same > consumer/loader is processing the message as it was originally processed. > However, if the message resubmit is happening during failover switch we have > noticed that the message is not sent to the right consumer as it should. > Basically the first available consumer is used which is not what we want. > I have searched for configuration changes but
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[ https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723982#comment-17723982 ] Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 5:31 PM: -- > This is a weakness in the application design which will lead to the same > problems with duplicate messages as you have when a broker failure causes the > consumer-group relationship to change. I am not seeing it as a weakness rather than an incomplete solution as we might still have duplicated messages (as you said) which in the end will fail during database import (see below). However, in the context of load balancing I think it is still better to have a local cache than nothing. There might be some other complex solutions indeed but this local cache will (still) help especially for those applications which do not have load balancing. > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, I have seen Kafka having idempotent consumers. Never used it though. was (Author: JIRAUSER300236): Regarding: > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, I have seen Kafka having idempotent consumers. Never used it though. > Message Group does not replicate properly during failover > - > > Key: ARTEMIS-4276 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4276 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > We are currently migrating our software from Classic to Artemis and we plan > to use failover functionality. > We were using message group functionality by setting *JMSXGroupID* and this > was working as expected. However after failover switch I noticed that > messages are sent to wrong consumers. > Our gateway/interface application is actually a collection of servers: > * gateway adapter server: receives messages from an external systems and > puts them on a specific/virtual topic > * gateway loader server (can be balanced): picks up the messages from the > topic and do processing > * gateway fail queue: monitors all messages that failed processing and has a > functionality of resubmitting the message (users will correct the processing > errors and then resubmit transaction) > *JMSXGroupID* is used to ensure that during message resubmit the same > consumer/loader is processing the message as it was originally processed. > However, if the message resubmit is happening during failover switch we have > noticed that the message is not sent to the right consumer as it should. > Basically the first available consumer is used which is not what we want. > I have searched for configuration changes but couldn't find any relevant > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[ https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723982#comment-17723982 ] Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 5:25 PM: -- Regarding: > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, I have seen Kafka having idempotent consumers. Never used it though. was (Author: JIRAUSER300236): Actually I think I understood what you meant :) Regarding: > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, Kafka has idempotent consumers. > Message Group does not replicate properly during failover > - > > Key: ARTEMIS-4276 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4276 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > We are currently migrating our software from Classic to Artemis and we plan > to use failover functionality. > We were using message group functionality by setting *JMSXGroupID* and this > was working as expected. However after failover switch I noticed that > messages are sent to wrong consumers. > Our gateway/interface application is actually a collection of servers: > * gateway adapter server: receives messages from an external systems and > puts them on a specific/virtual topic > * gateway loader server (can be balanced): picks up the messages from the > topic and do processing > * gateway fail queue: monitors all messages that failed processing and has a > functionality of resubmitting the message (users will correct the processing > errors and then resubmit transaction) > *JMSXGroupID* is used to ensure that during message resubmit the same > consumer/loader is processing the message as it was originally processed. > However, if the message resubmit is happening during failover switch we have > noticed that the message is not sent to the right consumer as it should. > Basically the first available consumer is used which is not what we want. > I have searched for configuration changes but couldn't find any relevant > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[ https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723982#comment-17723982 ] Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 5:16 PM: -- Actually I think I understood what you meant :) Regarding: > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course that our database IO meta layer has a mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications during failover switch. Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, Kafka has idempotent consumers. was (Author: JIRAUSER300236): Actually I think I understood what you meant :) Regarding: > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course our database IO meta layer we have mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, Kafka has idempotent consumers. > Message Group does not replicate properly during failover > - > > Key: ARTEMIS-4276 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4276 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > We are currently migrating our software from Classic to Artemis and we plan > to use failover functionality. > We were using message group functionality by setting *JMSXGroupID* and this > was working as expected. However after failover switch I noticed that > messages are sent to wrong consumers. > Our gateway/interface application is actually a collection of servers: > * gateway adapter server: receives messages from an external systems and > puts them on a specific/virtual topic > * gateway loader server (can be balanced): picks up the messages from the > topic and do processing > * gateway fail queue: monitors all messages that failed processing and has a > functionality of resubmitting the message (users will correct the processing > errors and then resubmit transaction) > *JMSXGroupID* is used to ensure that during message resubmit the same > consumer/loader is processing the message as it was originally processed. > However, if the message resubmit is happening during failover switch we have > noticed that the message is not sent to the right consumer as it should. > Basically the first available consumer is used which is not what we want. > I have searched for configuration changes but couldn't find any relevant > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4276) Message Group does not replicate properly during failover
[ https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723982#comment-17723982 ] Liviu Citu commented on ARTEMIS-4276: - Actually I think I understood what you meant :) Regarding: > This leads to the same transaction being imported in the database twice..." What I meant actually is that *_it will try to import_* the record in the database. Of course our database IO meta layer we have mechanism in place to avoid same transaction being imported twice (the database records have audit trail which include transaction version). This is because same database tables can also be affected by other applications part of our software (UI, batch utilities, etc) so it is not only the gateway interface who import data in the system. I just wanted to pin point a potential issue that could arise in applications Regarding: > Idempotency is something you, as the application developer, must implement. There are some third parties that have this out-of-the box. For instance, Kafka has idempotent consumers. > Message Group does not replicate properly during failover > - > > Key: ARTEMIS-4276 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4276 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > We are currently migrating our software from Classic to Artemis and we plan > to use failover functionality. > We were using message group functionality by setting *JMSXGroupID* and this > was working as expected. However after failover switch I noticed that > messages are sent to wrong consumers. > Our gateway/interface application is actually a collection of servers: > * gateway adapter server: receives messages from an external systems and > puts them on a specific/virtual topic > * gateway loader server (can be balanced): picks up the messages from the > topic and do processing > * gateway fail queue: monitors all messages that failed processing and has a > functionality of resubmitting the message (users will correct the processing > errors and then resubmit transaction) > *JMSXGroupID* is used to ensure that during message resubmit the same > consumer/loader is processing the message as it was originally processed. > However, if the message resubmit is happening during failover switch we have > noticed that the message is not sent to the right consumer as it should. > Basically the first available consumer is used which is not what we want. > I have searched for configuration changes but couldn't find any relevant > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722663#comment-17722663 ] Liviu Citu edited comment on ARTEMIS-4275 at 5/18/23 3:29 PM: -- Hi Justin, I saw your commit regarding _AMQ_ConsumerName and I have added a comment to it. Please have a look, Thanks [https://github.com/apache/activemq-artemis/commit/7da9bdf0a9b0d416ab4fa53c421ace27f3a44d0b#diff-96cdf8c4ff8d61ac9690fd5bfe2baefb4207074fc2bcd8a86d9122cb2f1ee1c2] was (Author: JIRAUSER300236): Hi Bertram, I saw your commit regarding _AMQ_ConsumerName and I have added a comment to it. Please have a look, Thanks https://github.com/apache/activemq-artemis/commit/7da9bdf0a9b0d416ab4fa53c421ace27f3a44d0b#diff-96cdf8c4ff8d61ac9690fd5bfe2baefb4207074fc2bcd8a86d9122cb2f1ee1c2 > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723810#comment-17723810
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 7:23 AM:
--
*Virtual Topics vs Shared Topic Consumers*
Our plan during migration from *Classic ActiveMQ* to *Artemis* is to modify as
little as possible the source code to reduce the regression impact.
Our software is C++ code based and we are using *CMS API* ({*}ActiveMQ CPP{*})
as a client. I am unable to find a CMS API to create shared topic consumer so I
am not sure if it exists. In the same time, I am not very sure that the
behavior of such LB using shared subscription is what we want in our Gateway
Loader Servers. We do not want to process the same message in more than one
group (please correct me if I am wrong):
[http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/]
Nonetheless we were using virtual topics with Classic ActiveMQ and they work as
expected with Artemis too (the setup changes are trivial).
*Idempotent consumer using local, volatile LRU cache*
*ActiveMQ CPP* does not have idempotent consumers. Nonetheless in our software
we have a wrapper over the CMS consumer and a wrapper over the CMS consumer
listener. The LRU cache is part of our listener. Indeed the *CMS consumer* gets
restored during failover but the object is not recreated so our wrapper is
still valid and the cache still stands in this context. Indeed this might not
be the best option to handle the duplicated messages but when there is no Load
Balance it works ok. The problem is indeed when there are more than one
consumer involved for the same topic.
*XA transaction*
The synchronization problem between database and JMS Broker is not necessary
related to failover or Artemis usage. We have this also with Classic ActiveMQ
[for instance if there is a network glitch or when ActiveMQ Broker goes down
and the message reached the database]. We were exploring the usage of XA
transaction however the code changes needed to implement it in an existing
software is huge and practically impossible.
*Handle duplicate messages at database level*
At the database level we have a protection with primary keys and indeed the
same transaction cannot be inserted twice. The problem with this is more like a
user notification problem.
As I have explained in the description of this issue, we have also a Gateway
Fail Queue Monitor where the users might find all messages that failed during
processing (included those duplicated that failed during insertion).
We just wanted to explore the possibility to have a way of removing these
"fake" failures caused by failover or somehow to distinguish them from those
which are real business failures. These are technical failures (cause by
failover in this case) and users looking to the Fail Queue Monitor might get
confused when seeing such duplicated messages without understanding what went
wrong (if indeed the same duplicated transaction was received from external
system of the duplicated message is caused by failover). I suppose they will
have to deal with this as being a system limitation.
was (Author: JIRAUSER300236):
*Virtual Topics vs Shared Topic Consumers*
Our plan during migration from *Classic ActiveMQ* to *Artemis* is to modify as
little as possible the source code to reduce the regression impact.
Our software is C++ code based and we are using *CMS API* ({*}ActiveMQ CPP{*})
as a client. I am unable to find a CMS API to create shared topic consumer so I
am not sure if it exists. In the same time, I am not very sure that the
behavior of such LB using shared subscription is what we want in our Gateway
Loader Servers. We do not want to process the same message in more than one
group (please correct me if I am wrong):
[http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/]
Nonetheless we were using virtual topics with Classic ActiveMQ and they work as
expected with Artemis too (the setup changes are trivial).
*Idempotent consumer using local, volatile LRU cache*
*ActiveMQ CPP* does not have idempotent consumers. Nonetheless in our software
we have a wrapper over the CMS consumer and a wrapper over the CMS consumer
listener. The LRU cache is part of our listener. Indeed the *CMS consumer* gets
restored during FailOver but the object is not recreated so our wrapper is
still valid and the cache still stands in this context. Indeed this might not
be the best option to handle the duplicated messages but when there is no Load
Balance it works ok. The problem is indeed when there are more than one
consumer involved for the same topic.
*XA transaction*
The synchronization problem between database and JMS Broker is not necessary
related to FailOver or Artemis usage. We have this also with Classic ActiveMQ
[for instance if there is a network glitch or when
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723810#comment-17723810
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 7:20 AM:
--
*Virtual Topics vs Shared Topic Consumers*
Our plan during migration from *Classic ActiveMQ* to *Artemis* is to modify as
little as possible the source code to reduce the regression impact.
Our software is C++ code based and we are using *CMS API* ({*}ActiveMQ CPP{*})
as a client. I am unable to find a CMS API to create shared topic consumer so I
am not sure if it exists. In the same time, I am not very sure that the
behavior of such LB using shared subscription is what we want in our Gateway
Loader Servers. We do not want to process the same message in more than one
group (please correct me if I am wrong):
[http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/]
Nonetheless we were using virtual topics with Classic ActiveMQ and they work as
expected with Artemis too (the setup changes are trivial).
*Idempotent consumer using local, volatile LRU cache*
*ActiveMQ CPP* does not have idempotent consumers. Nonetheless in our software
we have a wrapper over the CMS consumer and a wrapper over the CMS consumer
listener. The LRU cache is part of our listener. Indeed the *CMS consumer* gets
restored during FailOver but the object is not recreated so our wrapper is
still valid and the cache still stands in this context. Indeed this might not
be the best option to handle the duplicated messages but when there is no Load
Balance it works ok. The problem is indeed when there are more than one
consumer involved for the same topic.
*XA transaction*
The synchronization problem between database and JMS Broker is not necessary
related to FailOver or Artemis usage. We have this also with Classic ActiveMQ
[for instance if there is a network glitch or when *ActiveMQ* goes down and the
message reached the database]. We were exploring the usage of XA transaction
however the code changes needed to implement it in an existing software is huge
and practically impossible.
*Handle duplicate messages at database level*
At the database level we have a protection with primary keys and indeed the
same transaction cannot be inserted twice. The problem with this is more like a
user notification problem.
As I have explained in the description of this issue, we have also a Gateway
Fail Queue Monitor where the users might find all messages that failed during
processing (included those duplicated that failed during insertion).
We just wanted to explore the possibility to have a way of removing these
"fake" failures caused by FailOver or somehow to distinguish them from those
which are real business failures. These are technical failures (cause by
FailOver in this case) and users looking to the Fail Queue Monitor might get
confused when seeing such duplicated messages without understanding what went
wrong. I suppose they will have to deal with this as being a system limitation.
was (Author: JIRAUSER300236):
*Virtual Topics vs Shared Topic Consumers*
Our plan during migration from *Classic ActiveMQ* to *Artemis* is to modify as
little as possible the source code to reduce the regression impact.
Our software is C++ code based and we are using *CMS API* ({*}ActiveMQ CPP{*})
as a client. I am unable to find a CMS API to create shared topic consumer so I
am not sure if it exists. In the same time, I am not very sure that the
behavior of such LB using shared subscription is what we want in our Gateway
Loader Servers. We do not want to process the same message in more than one
group (please correct me if I am wrong):
[http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/]
Nonetheless we were using virtual topics with Classic ActiveMQ and they work as
expected with Artemis too (the setup changes are trivial).
*Idempotent consumer using local, volatile LRU cache*
*ActiveMQ CPP* does not have idempotent consumers. Nonetheless in our software
we have a wrapper over the CMS consumer and a wrapper over the CMS consumer
listener. The LRU cache is part of our listener. Indeed the *CMS consumer* gets
restored during FailOver but the object is not recreated so our wrapper is
still valid and the cache still stands in this context. Indeed this might not
be the best option to handle the duplicated messages but when there is no Load
Balance it works ok. The problem is indeed when there are more than one
consumer involved for the same topic.
*XA transaction*
The synchronization problem between database and JMS Broker is not necessary
related to FailOver or Artemis usage. We have this also with Classic ActiveMQ
[for instance if there is a network glitch or when *ActiveMQ* goes down and the
message reached the database]. We were exploring the usage of XA transaction
however the code changes
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723810#comment-17723810
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/18/23 7:18 AM:
--
*Virtual Topics vs Shared Topic Consumers*
Our plan during migration from *Classic ActiveMQ* to *Artemis* is to modify as
little as possible the source code to reduce the regression impact.
Our software is C++ code based and we are using *CMS API* ({*}ActiveMQ CPP{*})
as a client. I am unable to find a CMS API to create shared topic consumer so I
am not sure if it exists. In the same time, I am not very sure that the
behavior of such LB using shared subscription is what we want in our Gateway
Loader Servers. We do not want to process the same message in more than one
group (please correct me if I am wrong):
[http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/]
Nonetheless we were using virtual topics with Classic ActiveMQ and they work as
expected with Artemis too (the setup changes are trivial).
*Idempotent consumer using local, volatile LRU cache*
*ActiveMQ CPP* does not have idempotent consumers. Nonetheless in our software
we have a wrapper over the CMS consumer and a wrapper over the CMS consumer
listener. The LRU cache is part of our listener. Indeed the *CMS consumer* gets
restored during FailOver but the object is not recreated so our wrapper is
still valid and the cache still stands in this context. Indeed this might not
be the best option to handle the duplicated messages but when there is no Load
Balance it works ok. The problem is indeed when there are more than one
consumer involved for the same topic.
*XA transaction*
The synchronization problem between database and JMS Broker is not necessary
related to FailOver or Artemis usage. We have this also with Classic ActiveMQ
[for instance if there is a network glitch or when *ActiveMQ* goes down and the
message reached the database]. We were exploring the usage of XA transaction
however the code changes needed to implement it in an existing software is huge
and practically impossible. However, at the database level we have a protection
with primary keys and indeed the same transaction cannot be processed twice.
As I have explained in the description of this issue, we have also a Gateway
Fail Queue Monitor where the users might find all messages that failed during
processing (included those duplicated that failed during insertion).
We just wanted to explore the possibility to have a way of removing these
"fake" failures caused by FailOver or somehow to distinguish them from those
which are real business failures. These are technical failures (cause by
FailOver in this case) and users looking to the Fail Queue Monitor might get
confused when seeing such duplicated messages without understanding what went
wrong. I suppose they will have to deal with this as being a system limitation.
was (Author: JIRAUSER300236):
*Virtual Topics vs Shared Topic Consumers*
Our plan during migration from *Classic ActiveMQ* to *Artemis* is to modify as
little as possible the source code to reduce the regression impact.
Our software is C++ code based and we are using *CMS API* ({*}ActiveMQ CPP{*})
as a client. I am unable to find a CMS API to create shared topic consumer so I
am not sure if it exists. In the same time, I am not very sure that the
behavior of such LB using shared subscription is what we want in our Gateway
Loader Servers. We do not want to process the same message in more than one
group (please correct me if I am wrong):
http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/
Nonetheless we were using virtual topics with Classic ActiveMQ and they work as
expected with Artemis too (the setup changes are trivial).
*Idempotent consumer using local, volatile LRU cache*
*ActiveMQ CPP* does not support idempotent consumers. Nonetheless in our
software we have a wrapper over the CMS consumer and a wrapper over the CMS
consumer listener. The LRU cache is part of our listener. Indeed the *CMS
consumer* gets restored during FailOver but the object is not recreated so our
wrapper is still valid and the cache still stands in this context. Indeed this
might not be the best option to handle the duplicated messages but when there
is no Load Balance it works ok. The problem is indeed when there are more than
one consumer involved for the same topic.
*XA transaction*
The synchronization problem between database and JMS Broker is not necessary
related to FailOver or Artemis usage. We have this also with Classic ActiveMQ
[for instance if there is a network glitch or when *ActiveMQ* goes down and the
message reached the database]. We were exploring the usage of XA transaction
however the code changes needed to implement it in an existing software is huge
and practically impossible. However, at the
[jira] [Commented] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723810#comment-17723810
]
Liviu Citu commented on ARTEMIS-4276:
-
*Virtual Topics vs Shared Topic Consumers*
Our plan during migration from *Classic ActiveMQ* to *Artemis* is to modify as
little as possible the source code to reduce the regression impact.
Our software is C++ code based and we are using *CMS API* ({*}ActiveMQ CPP{*})
as a client. I am unable to find a CMS API to create shared topic consumer so I
am not sure if it exists. In the same time, I am not very sure that the
behavior of such LB using shared subscription is what we want in our Gateway
Loader Servers. We do not want to process the same message in more than one
group (please correct me if I am wrong):
http://jmesnil.net/weblog/2013/06/27/jms-20-shared-subscription/
Nonetheless we were using virtual topics with Classic ActiveMQ and they work as
expected with Artemis too (the setup changes are trivial).
*Idempotent consumer using local, volatile LRU cache*
*ActiveMQ CPP* does not support idempotent consumers. Nonetheless in our
software we have a wrapper over the CMS consumer and a wrapper over the CMS
consumer listener. The LRU cache is part of our listener. Indeed the *CMS
consumer* gets restored during FailOver but the object is not recreated so our
wrapper is still valid and the cache still stands in this context. Indeed this
might not be the best option to handle the duplicated messages but when there
is no Load Balance it works ok. The problem is indeed when there are more than
one consumer involved for the same topic.
*XA transaction*
The synchronization problem between database and JMS Broker is not necessary
related to FailOver or Artemis usage. We have this also with Classic ActiveMQ
[for instance if there is a network glitch or when *ActiveMQ* goes down and the
message reached the database]. We were exploring the usage of XA transaction
however the code changes needed to implement it in an existing software is huge
and practically impossible. However, at the database level we have a protection
with primary keys and indeed the same transaction cannot be processed twice.
As I have explained in the description of this issue, we have also a Gateway
Fail Queue Monitor where the users might find all messages that failed during
processing (included those duplicated that failed during insertion).
We just wanted to explore the possibility to have a way of removing these
"fake" failures caused by FailOver or somehow to distinguish them from those
which are real business failures. These are technical failures (cause by
FailOver in this case) and users looking to the Fail Queue Monitor might get
confused when seeing such duplicated messages without understanding what went
wrong. I suppose they will have to deal with this as being a system limitation.
> Message Group does not replicate properly during failover
> -
>
> Key: ARTEMIS-4276
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4276
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.28.0
>Reporter: Liviu Citu
>Priority: Major
>
> Hi,
> We are currently migrating our software from Classic to Artemis and we plan
> to use failover functionality.
> We were using message group functionality by setting *JMSXGroupID* and this
> was working as expected. However after failover switch I noticed that
> messages are sent to wrong consumers.
> Our gateway/interface application is actually a collection of servers:
> * gateway adapter server: receives messages from an external systems and
> puts them on a specific/virtual topic
> * gateway loader server (can be balanced): picks up the messages from the
> topic and do processing
> * gateway fail queue: monitors all messages that failed processing and has a
> functionality of resubmitting the message (users will correct the processing
> errors and then resubmit transaction)
> *JMSXGroupID* is used to ensure that during message resubmit the same
> consumer/loader is processing the message as it was originally processed.
> However, if the message resubmit is happening during failover switch we have
> noticed that the message is not sent to the right consumer as it should.
> Basically the first available consumer is used which is not what we want.
> I have searched for configuration changes but couldn't find any relevant
> information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 1:11 PM:
--
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose we have a gateway interfaces with an external system to import
transactions into the database. Such interface consists of two main components:
* {*}gateway adapter server (producer){*}: *receives* messages from the
external systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: *consumes* messages from the adapter
JMS topic, does some processing and *saves* transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual topics* for that.
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
Assume external transaction is identified by
*ExternalSystem+ExternalType+ExternalID.* Thee gateway adapter will set
*JMSXGroupID* to this value in the JMS message before sending it to the topic.
If a new version of the same transaction is received from external system then
the same *JMSXGroupID* will be set in the message.
Practical example:
*EXT_SWAP_ID* with version *1* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_SWAP_ID* with version *2* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_BOND_ID* with version *1* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *2* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *3* will have *JMSXGroupID=EXT_BOND_ID*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID{*}
*LDR2* have processed all messages having {*}JMSXGroupID={*}{*}EXT_BOND_ID{*}
Just before doing failover switch, we have received two new transactions:
*EXT_SWAP_ID* with version *3* ({*}JMSXGroupID=EXT_SWAP_ID){*}
*EXT_BOND_ID* with version {*}4 ({*}{*}JMSXGroupID=EXT_BOND_ID){*}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID* with version *3*
*LDR2* has processed *EXT_BOND_ID* with version *4*
However *broker was not able to receive message acknowledgement due to network
interruption (failover switch).* After the broker is back online it sends again
the two messages to its consumers.
To handle a message duplication all our consumer's listeners are using a *LRU*
(last recently used) cache of the already processed messages. So if a same
message is being received twice then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID* with version *3* will skip it.
if *LDR2* will receive again *EXT_BOND_ID* with version *4* will skip it.
However, the problem is that after failover switch the transactions are
received the other way around:
*LDR1* received *EXT_BOND_ID* with version *4*
*LDR2* received *EXT_SWAP_ID* with version *3*
*LDR1* and *LDR2* being separate processes they cannot share their *LRU* cache
as this is an in-memory cache. Therefore these messages are considered new to
the loaders because they are not part of their LRU cache and hence loaders will
try to process these transactions.
This leads to the same transaction being imported in the database twice and
causing several other issues in our application. Actually these transactions
re-import might fail entirely and in some cases will cause both *LDR1* and
*LDR2* to malfunction.
Is there any setup to circumvent this? Is the grouping cached used by the
broker distributed or persisted during te failover switch?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose we have a gateway interfaces with an external system to import
transactions into the database. Such interface consists of two main components:
* {*}gateway adapter server (producer){*}: *receives* messages from the
external systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: *consumes* messages from the adapter
JMS topic, does some processing and *saves*
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:40 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose we have a gateway interfaces with an external system to import
transactions into the database. Such interface consists of two main components:
* {*}gateway adapter server (producer){*}: *receives* messages from the
external systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: *consumes* messages from the adapter
JMS topic, does some processing and *saves* transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual topics* for that.
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
Assume external transaction is identified by
*ExternalSystem+ExternalType+ExternalID.* Thee gateway adapter will set
*JMSXGroupID* to this value in the JMS message before sending it to the topic.
If a new version of the same transaction is received from external system then
the same *JMSXGroupID* will be set in the message.
Practical example:
*EXT_SWAP_ID* with version *1* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_SWAP_ID* with version *2* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_BOND_ID* with version *1* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *2* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *3* will have *JMSXGroupID=EXT_BOND_ID*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID{*}
*LDR2* have processed all messages having {*}JMSXGroupID={*}{*}EXT_BOND_ID{*}
Just before doing failover switch, we have received two new transactions:
*EXT_SWAP_ID* with version *3* ({*}JMSXGroupID=EXT_SWAP_ID){*}
*EXT_BOND_ID* with version {*}4 ({*}{*}JMSXGroupID=EXT_BOND_ID){*}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID* with version *3*
*LDR2* has processed *EXT_BOND_ID* with version *4*
However *broker was not able to receive message acknowledgement due to network
interruption (failover switch).* After the broker is back online it sends again
the two messages to its consumers.
To handle a message duplication all our consumer's listeners are using a *LRU*
(last recently used) cache of the already processed messages. So if a same
message is being received twice then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID* with version *3* will skip it.
if *LDR2* will receive again *EXT_BOND_ID* with version *4* will skip it.
However, the problem is that after failover switch the transactions are
received the other way around:
*LDR1* received *EXT_BOND_ID* with version *4*
*LDR2* received *EXT_SWAP_ID* with version *3*
*LDR1* and *LDR2* being separate processes they cannot share their *LRU* cache
as this is an in-memory cache. Therefore these messages are considered new to
the loaders because they are not part of their LRU cache and hence loaders will
try to process these transactions.
This leads to the same transaction being imported in the database twice and
causing several other issues in our application. Actually these transactions
re-import might fail entirely and in some cases will cause both *LDR1* and
*LDR2* to malfunction properly.
Is there any setup to circumvent this? Is the grouping cached used by the
broker distributed or persisted during te failover switch?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose we have a gateway interfaces with an external system to import
transactions into the database. Such interface consists of two main components:
* {*}gateway adapter server (producer){*}: *receives* messages from the
external systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: *consumes* messages from the adapter
JMS topic, does some processing and
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:39 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose we have a gateway interfaces with an external system to import
transactions into the database. Such interface consists of two main components:
* {*}gateway adapter server (producer){*}: *receives* messages from the
external systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: *consumes* messages from the adapter
JMS topic, does some processing and *saves* transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual topics* for that.
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
Assume external transaction is identified by
*ExternalSystem+ExternalType+ExternalID.* Thee gateway adapter will set
*JMSXGroupID* to this value in the JMS message before sending it to the topic.
If a new version of the same transaction is received from external system then
the same *JMSXGroupID* will be set in the message.
Practical example:
*EXT_SWAP_ID* with version *1* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_SWAP_ID* with version *2* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_BOND_ID* with version *1* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *2* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *3* will have *JMSXGroupID=EXT_BOND_ID*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID{*}
*LDR2* have processed all messages having {*}JMSXGroupID={*}{*}EXT_BOND_ID{*}
Just before doing failover switch, we have received two new transactions:
*EXT_SWAP_ID* with version *3* ({*}JMSXGroupID=EXT_SWAP_ID){*}
*EXT_BOND_ID* with version {*}4 ({*}{*}JMSXGroupID=EXT_BOND_ID){*}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID* with version *3*
*LDR2* has processed *EXT_BOND_ID* with version *4*
However *broker was not able to receive message acknowledgement due to network
interruption (failover switch).* After the broker is back online it sends again
the two messages to its consumers.
To handle a message duplication all our consumer's listeners are using a *LRU*
(last recently used) cache of the already processed messages. So if a same
message is being received twice then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID* with version *3* will skip it.
if *LDR2* will receive again *EXT_BOND_ID* with version *4* will skip it.
However, the problem is that after failover switch the transactions are
received the other way around:
*LDR1* received *EXT_BOND_ID* with version *4*
*LDR2* received *EXT_SWAP_ID* with version *3*
*DR1* and *LDR2* being separate processes they cannot share their *LRU* cache
as this is an in-memory cache. Therefore these messages are considered new to
the loaders because they are not part of their LRU cache and hence loaders will
try to process these transactions.
This leads to the same transaction being imported in the database twice and
causing several other issues in our application. Actually these transactions
re-import might fail entirely and in some cases will cause both *LDR1* and
*LDR2* to malfunction properly.
Is there any setup to circumvent this? Is the grouping cached used by the
broker distributed or persisted during te failover switch?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose we have a gateway interfaces with an external system to import
transactions into the database. Such interface consists of two main components:
* {*}gateway adapter server (producer){*}: *receives* messages from the
external systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: *consumes* messages from the adapter
JMS topic, does some processing and
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:35 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose we have a gateway interfaces with an external system to import
transactions into the database. Such interface consists of two main components:
* {*}gateway adapter server (producer){*}: *receives* messages from the
external systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: *consumes* messages from the adapter
JMS topic, does some processing and *saves* transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual topics* for that.
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
Assume external transaction is identified by
*ExternalSystem+ExternalType+ExternalID.* Thee gateway adapter will set
*JMSXGroupID* to this value in the JMS message before sending it to the topic.
If a new version of the same transaction is received from external system then
the same *JMSXGroupID* will be set in the message.
Practical example:
*EXT_SWAP_ID* with version *1* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_SWAP_ID* with version *2* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_BOND_ID* with version *1* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *2* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *3* will have *JMSXGroupID=EXT_BOND_ID*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID{*}
*LDR2* have processed all messages having {*}JMSXGroupID={*}{*}EXT_BOND_ID{*}
During failover switched we have received two new transactions:
*EXT_SWAP_ID* with version *3* ({*}JMSXGroupID=EXT_SWAP_ID){*}
*EXT_BOND_ID* with version {*}4 ({*}{*}JMSXGroupID=EXT_BOND_ID){*}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID* with version *3*
*LDR2* has processed *EXT_BOND_ID* with version *4*
However broker was not able to receive message acknowledgement due to network
interruption (failover switch). After the broker is online it sends again the
two messages to its consumers.
To handle a message duplication all our consumer listeners are using a *LRU*
(last recently used) cache of the already processed messages. So if a same
message is being received twice then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID* with version *3* will skip it.
if *LDR2* will receive again *EXT_BOND_ID* with version *4* will skip it.
However, the problem is that after failover switch the transactions are
received the other way around:
*LDR1* received *EXT_BOND_ID* with version *4*
*LDR2* received *EXT_SWAP_ID* with version *3*
These messages are considered new to the loaders because they are not in their
LRU cache and hence they will try to process these transactions. LDR1 and LDR2
are separate processes which are not sharing their internal/in-memory resources
(aka LRU cache).
This leads to the same transaction being imported in the database twice and
causing several other issues in our application. Actually these transactions
re-import might fail entirely and in some cases will cause both *LDR1* and
*LDR2* to malfunction properly.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:34 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual topics* for that.
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
Assume external transaction is identified by
*ExternalSystem+ExternalType+ExternalID.* Thee gateway adapter will set
*JMSXGroupID* to this value in the JMS message before sending it to the topic.
If a new version of the same transaction is received from external system then
the same *JMSXGroupID* will be set in the message.
Practical example:
*EXT_SWAP_ID* with version *1* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_SWAP_ID* with version *2* will have *JMSXGroupID=EXT_SWAP_ID*
*EXT_BOND_ID* with version *1* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *2* will have *JMSXGroupID=EXT_BOND_ID*
*EXT_BOND_ID* with version *3* will have *JMSXGroupID=EXT_BOND_ID*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID{*}
*LDR2* have processed all messages having {*}JMSXGroupID={*}{*}EXT_BOND_ID{*}
During failover switched we have received two new transactions:
*EXT_SWAP_ID* with version *3* ({*}JMSXGroupID=EXT_SWAP_ID){*}
*EXT_BOND_ID* with version {*}4 ({*}{*}JMSXGroupID=EXT_BOND_ID){*}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID* with version *3*
*LDR2* has processed *EXT_BOND_ID* with version *4*
However broker was not able to receive message acknowledgement due to network
interruption (failover switch). After the broker is online it sends again the
two messages to its consumers.
To handle a message duplication all our consumer listeners are using a *LRU*
(last recently used) cache of the already processed messages. So if a same
message is being received twice then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID* with version *3* will skip it.
if *LDR2* will receive again *EXT_BOND_ID* with version *4* will skip it.
However, the problem is that after failover switch the transactions are
received the other way around:
*LDR1* received *EXT_BOND_ID* with version *4*
*LDR2* received *EXT_SWAP_ID* with version *3*
These messages are considered new to the loaders because they are not in their
LRU cache and hence they will try to process these transactions. LDR1 and LDR2
are separate processes which are not sharing their internal/in-memory resources
(aka LRU cache).
This leads to the same transaction being imported in the database twice and
causing several other issues in our application. Actually these transactions
re-import might fail entirely and in some cases will cause both *LDR1* and
*LDR2* to malfunction properly.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:29 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual topics* for that.
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
Assume external transaction is identified by
*ExternalSystem+ExternalType+ExternalID.* Thee gateway adapter will set
*JMSXGroupID* to this value in the JMS message before sending it to the topic.
If a new version of the same transaction is received from external system then
the same *JMSXGroupID* will be set in the message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 3 will have *JMSXGroupID=EXT_BOND_ID1*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{{*}}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{{*}}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* has processed *EXT_BOND_ID1* with version 4
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_SWAP_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing several other issues in
our application. Actually these transactions re-import might fail now and in
some cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:29 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same topic. We are using
*virtual topics* for that.
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
External transaction is identified by *ExternalSystem+ExternalType+ExternalID.*
Thee gateway adapter will set *JMSXGroupID* to this value in the JMS message
before sending it to the topic. If a new version of the same transaction is
received from external system then the same *JMSXGroupID* will be set in the
message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 3 will have *JMSXGroupID=EXT_BOND_ID1*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{{*}}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{{*}}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* has processed *EXT_BOND_ID1* with version 4
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_SWAP_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing several other issues in
our application. Actually these transactions re-import might fail now and in
some cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same producer. We can have
multiple consumers
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:28 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Suppose your software have some gateway interfaces with external systems to
import transactions into the database. Such interface consists of two main
components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same producer. We can have
multiple consumers of the same topic by using *virtual topics.*
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
External transaction is identified by *ExternalSystem+ExternalType+ExternalID.*
Thee gateway adapter will set *JMSXGroupID* to this value in the JMS message
before sending it to the topic. If a new version of the same transaction is
received from external system then the same *JMSXGroupID* will be set in the
message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 3 will have *JMSXGroupID=EXT_BOND_ID1*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{{*}}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{{*}}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* has processed *EXT_BOND_ID1* with version 4
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_SWAP_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing several other issues in
our application. Actually these transactions re-import might fail now and in
some cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Our software is using *ActiveMQ* JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:27 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using *ActiveMQ* JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same producer. We can have
multiple consumers of the same topic by using *virtual topics.*
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
External transaction is identified by *ExternalSystem+ExternalType+ExternalID.*
Thee gateway adapter will set *JMSXGroupID* to this value in the JMS message
before sending it to the topic. If a new version of the same transaction is
received from external system then the same *JMSXGroupID* will be set in the
message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 3 will have *JMSXGroupID=EXT_BOND_ID1*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{{*}}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{{*}}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* has processed *EXT_BOND_ID1* with version 4
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_SWAP_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing several other issues in
our application. Actually these transactions re-import might fail now and in
some cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using ActiveMQ JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:27 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used during failover switch.
Let me provide some more details to better understand the business case.
Our software is using *ActiveMQ* JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same producer. We can have
multiple consumers of the same topic by using *virtual topics.*
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
External transaction is identified by *ExternalSystem+ExternalType+ExternalID.*
Thee gateway adapter will set *JMSXGroupID* to this value in the JMS message
before sending it to the topic. If a new version of the same transaction is
received from external system then the same *JMSXGroupID* will be set in the
message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 3 will have *JMSXGroupID=EXT_BOND_ID1*
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{{*}}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{{*}}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* has processed *EXT_BOND_ID1* with version 4
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_SWAP_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing several other issues in
our application. Actually these transactions re-import might fail now and in
some cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using *ActiveMQ* JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:25 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using ActiveMQ JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same producer. We can have
multiple consumers of the same topic by using *virtual topics.*
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
External transaction is identified by *ExternalSystem+ExternalType+ExternalID.*
Thee gateway adapter will set *JMSXGroupID* to this value in the JMS message
before sending it to the topic. If a new version of the same transaction is
received from external system then the same *JMSXGroupID* will be set in the
message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 3 will have {*}JMSXGroupID=EXT_BOND_ID1{*}{*}{{*}}
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{{*}}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{{*}}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* has processed *EXT_BOND_ID1* with version 4
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_SWAP_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing issues from financial
point of view. Actually these transactions re-import might fail now and in some
cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using ActiveMQ JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very
[jira] [Comment Edited] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu edited comment on ARTEMIS-4276 at 5/17/23 11:24 AM:
---
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using ActiveMQ JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same producer. We can have
multiple consumers of the same topic by using *virtual topics.*
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
External transaction is identified by *ExternalSystem+ExternalType+ExternalID.*
Thee gateway adapter will set *JMSXGroupID* to this value in the JMS message
before sending it to the topic. If a new version of the same transaction is
received from external system then the same *JMSXGroupID* will be set in the
message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 3 will have {*}JMSXGroupID=EXT_BOND_ID1{*}{*}{{*}}
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{{*}}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{{*}}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* ** has processed *EXT_BOND_ID1* with version 4{*}{{*}}
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* ** will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_BOND_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing issues from financial
point of view. Actually these transactions re-import might fail now and in some
cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
was (Author: JIRAUSER300236):
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using ActiveMQ JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message
[jira] [Commented] (ARTEMIS-4276) Message Group does not replicate properly during failover
[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723419#comment-17723419
]
Liviu Citu commented on ARTEMIS-4276:
-
The question is more like in the context of dealing with message duplication
when grouping is being used.
Let me provide some more details to better understand the business case.
Our software is using ActiveMQ JMS Broker for message distribution across all
of its clients and servers. We have some gateway interfaces with external
systems to import transactions into the database. Such interface consists of
two main components:
* {*}gateway adapter server (producer){*}: receives messages from the external
systems using some APIs and *puts* them on a specific JMS topic
* {*}gateway loader server (consumer){*}: consumes messages from the adapter
JMS topic, do some processing and save transaction into the database
As the processing is time consuming and the message volumes is very high then
we have to *balance the gateway loader server* (two or more loader
servers/consumers can be configured to listen to the same producer. We can have
multiple consumers of the same topic by using *virtual topics.*
These external transactions have versioning so we need to ensure that they are
processed in a specific order (actually in the order they are received). To
ensure that we are using *JMSXGroupID* which will identity the transaction
without its version. By using grouping we ensure that the same consumer will
process all versions of the same transaction.
External transaction is identified by *ExternalSystem+ExternalType+ExternalID.*
Thee gateway adapter will set *JMSXGroupID* to this value in the JMS message
before sending it to the topic. If a new version of the same transaction is
received from external system then the same *JMSXGroupID* will be set in the
message.
Practical example:
*EXT_SWAP_ID1* with version 1 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_SWAP_ID1* with version 2 will have *JMSXGroupID=EXT_SWAP_ID1*
*EXT_BOND_ID1* with version 1 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* with version 2 will have *JMSXGroupID=EXT_BOND_ID1*
*EXT_BOND_ID1* ** with version 3 will have **
{*}JMSXGroupID=EXT_BOND_ID1{*}{*}{*}
Let's assume we have two loaders (consumers): *LDR1* and *LDR2* .
Prior to failover we know that:
*LDR1* have processed all messages having {*}JMSXGroupID={*}{*}EXT_SWAP_ID1{*}
*LDR2* ** have processed all messages having
{*}JMSXGroupID={*}{*}EXT_BOND_ID1{*}{*}{*}
During failover switched we have received two transactions:
*EXT_SWAP_ID1* with version 3 ({*}JMSXGroupID=EXT_SWAP_ID1){*}
*EXT_BOND_ID1* with version 4 {*}({*}{*}JMSXGroupID=EXT_BOND_ID1){*}{*}{*}
*LDR1* and *LDR2* were able to process the transactions meaning:
*LDR1* has processed *EXT_SWAP_ID1* with version 3
*LDR2* ** has processed *EXT_BOND_ID1* with version 4{*}{*}
However when they sent the message acknowledge to the broker then the broker
was not able to receive them due to network interruption (failover switch).
After the broker is online it sends again the two messages to its consumers.
To handle a message duplication all our consumer listeners are using a LRU
(last recently used) cache of the already processed messages. So if a same
message is being received then it will be skipped. Therefore:
if *LDR1* will receive again *EXT_SWAP_ID1* with version 3 will skip it.
if *LDR2* ** will receive again *EXT_BOND_ID1* with version 4 will skip it.
However, the problem is that after failover switch:
*LDR1* received *EXT_BOND_ID1* with version 4
*LDR2* received *EXT_BOND_ID1* with version 3
These messages are considered new to them because they are not in their LRU
cache and hence will try to process the transactions. This leads to the same
transaction being imported in the database and causing issues from financial
point of view. Actually these transactions re-import might fail now and in some
cases will cause both *LDR1* and *LDR2* to stop processing.
Is there any setup to circumvent this?
> Message Group does not replicate properly during failover
> -
>
> Key: ARTEMIS-4276
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4276
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.28.0
>Reporter: Liviu Citu
>Priority: Major
>
> Hi,
> We are currently migrating our software from Classic to Artemis and we plan
> to use failover functionality.
> We were using message group functionality by setting *JMSXGroupID* and this
> was working as expected. However after failover switch I noticed that
> messages are sent to wrong consumers.
> Our gateway/interface application is actually a collection of servers:
> * gateway adapter server: receives messages from an external systems and
> puts
[jira] [Commented] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722663#comment-17722663 ] Liviu Citu commented on ARTEMIS-4275: - Hi Bertram, I saw your commit regarding _AMQ_ConsumerName and I have added a comment to it. Please have a look, Thanks https://github.com/apache/activemq-artemis/commit/7da9bdf0a9b0d416ab4fa53c421ace27f3a44d0b#diff-96cdf8c4ff8d61ac9690fd5bfe2baefb4207074fc2bcd8a86d9122cb2f1ee1c2 > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721478#comment-17721478 ] Liviu Citu commented on ARTEMIS-4275: - I totally agree with that statement. Our software is using intensively *JMS* *ActiveMQ Broker* and we want to migrate to *Artemis Broker* to benefit of the new features. We will be using Notification Messages as a replacement for Advisory Messages. Thank you for the change! > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4276) Message Group does not replicate properly during failover
Liviu Citu created ARTEMIS-4276: --- Summary: Message Group does not replicate properly during failover Key: ARTEMIS-4276 URL: https://issues.apache.org/jira/browse/ARTEMIS-4276 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.28.0 Reporter: Liviu Citu Hi, We are currently migrating our software from Classic to Artemis and we plan to use failover functionality. We were using message group functionality by setting *JMSXGroupID* and this was working as expected. However after failover switch I noticed that messages are sent to wrong consumers. Our gateway/interface application is actually a collection of servers: * gateway adapter server: receives messages from an external systems and puts them on a specific/virtual topic * gateway loader server (can be balanced): picks up the messages from the topic and do processing * gateway fail queue: monitors all messages that failed processing and has a functionality of resubmitting the message (users will correct the processing errors and then resubmit transaction) *JMSXGroupID* is used to ensure that during message resubmit the same consumer/loader is processing the message as it was originally processed. However, if the message resubmit is happening during failover switch we have noticed that the message is not sent to the right consumer as it should. Basically the first available consumer is used which is not what we want. I have searched for configuration changes but couldn't find any relevant information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Citu updated ARTEMIS-4275: Description: Hi, *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / CONSUMER_CLOSED* notification messages. This property is necessary to identify the *ConsumerId.* In a subscription model functionality the server needs to know when a certain subscription (consumer) gets created or closed. I have tried to use *_AMQ_RoutingName* but it seems it is for different purposes (sometimes it is simply equal with *_AMQ_Address).* *_AMQ_ConsumerName* was available in the Advisory Message but it does not seem to be part of the Notification Message. Therefore this is a regression compared to Classic ActiveMQ. Regards Liviu was: Hi, *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / CONSUMER_CLOSED* notification messages. This property is necessary to identify to identify the *ConsumerId.* In a subscription model functionality the server needs to know when a certain subscription (consumer) gets created or closed. I have tried to use *_AMQ_RoutingName* but it seems it is for different purposes (sometimes it is simply equal with *_AMQ_Address).* *_AMQ_ConsumerName* was available in the Advisory Message but it does not seem to be part of the Notification Message. Therefore this is a regression compared to Classic ActiveMQ. Regards Liviu > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721374#comment-17721374 ] Liviu Citu commented on ARTEMIS-2824: - I have logged: ARTEMIS-4275 > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
Liviu Citu created ARTEMIS-4275: --- Summary: _AMQ_ConsumerName is missing from Consumer Created/Closed notifications Key: ARTEMIS-4275 URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.28.0 Reporter: Liviu Citu Hi, *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / CONSUMER_CLOSED* notification messages. This property is necessary to identify to identify the *ConsumerId.* In a subscription model functionality the server needs to know when a certain subscription (consumer) gets created or closed. I have tried to use *_AMQ_RoutingName* but it seems it is for different purposes (sometimes it is simply equal with *_AMQ_Address).* *_AMQ_ConsumerName* was available in the Advisory Message but it does not seem to be part of the Notification Message. Therefore this is a regression compared to Classic ActiveMQ. Regards Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721294#comment-17721294 ] Liviu Citu edited comment on ARTEMIS-2824 at 5/10/23 11:02 AM: --- Hi Justin, *_AMQ_ConsumerName* property is also missing from *CONSUMER_CREATED / CONSUMER_CLOSED* notification messages. Is it possible to set it? I need this property to identify the *ConsumerId.* We are using a subscription model functionality and on one of our servers we need to know when a certain subscription (consumer) gets created or closed. I have tried to use *_AMQ_RoutingName* but it seems it is for different purposes (in some cases when temporary queues are involved it seems to be the same as *_AMQ_Address).* *_AMQ_ConsumerName* was available in the Advisory Message but it does not seem to be part of the Notification Message. Please let me know if I should log a separate issues for it. Thank you! was (Author: JIRAUSER300236): Hi Justin, *_AMQ_ConsumerName* property is also missing from *CONSUMER_CREATED / CONSUMER_CLOSED* notification messages. Is it possible to set it? I need this property to identify the *ConsumerId.* We are using a subscription model functionality and on one of our servers we need to know when a certain subscription (consumer of a specific topic) gets created or closed. This property was available in the Advisory Message but it does not seem to be part of the Notification Message. Please let me know if I should log a separate issues for it. Thank you! > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721294#comment-17721294 ] Liviu Citu edited comment on ARTEMIS-2824 at 5/10/23 10:58 AM: --- Hi Justin, *_AMQ_ConsumerName* property is also missing from *CONSUMER_CREATED / CONSUMER_CLOSED* notification messages. Is it possible to set it? I need this property to identify the *ConsumerId.* We are using a subscription model functionality and on one of our servers we need to know when a certain subscription (consumer of a specific topic) gets created or closed. This property was available in the Advisory Message but it does not seem to be part of the Notification Message. Please let me know if I should log a separate issues for it. Thank you! was (Author: JIRAUSER300236): Hi Justin, *_AMQ_ConsumerName* property is also missing from *CONSUMER_CREATED / CONSUMER_CLOSED* notification messages. Is it possible to set it? I need this property to identify the *ConsumerId.* We are using a subscription model functionality and on the server side we need to know when a certain consumer (subscription) gets created or closed. This property was available in the Advisory Message but it does not seem to be part of the Notification Message. Please let me know if I should log a separate issues for it. Thank you! > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[
https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721294#comment-17721294
]
Liviu Citu edited comment on ARTEMIS-2824 at 5/10/23 10:57 AM:
---
Hi Justin,
*_AMQ_ConsumerName* property is also missing from *CONSUMER_CREATED /
CONSUMER_CLOSED* notification messages. Is it possible to set it? I need this
property to identify the *ConsumerId.* We are using a subscription model
functionality and on the server side we need to know when a certain consumer
(subscription) gets created or closed.
This property was available in the Advisory Message but it does not seem to be
part of the Notification Message.
Please let me know if I should log a separate issues for it.
Thank you!
was (Author: JIRAUSER300236):
Hi Justin,
*_AMQ_ConsumerName* property is also missing from *CONSUMER_CREATED /
CONSUMER_CLOSED* notification messages. Is it possible to set it? I need this
property to identify the {*}ConsumerId{*}. This property was available in the
Advisory Message but it does not seem to be part of the Notification Message.
Please let me know if I should log a separate issues for it.
Thank you!
> _AMQ_Client_ID on SESSION_CLOSED notification is always null
>
>
> Key: ARTEMIS-2824
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2824
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Tim Daly
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a JMS client with a clientId set closes the session a notification
> (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID
> is always set to null. The JMS Client Id has been verified as being set via
> the web UI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[
https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721294#comment-17721294
]
Liviu Citu commented on ARTEMIS-2824:
-
Hi Justin,
*_AMQ_ConsumerName* property is also missing from *CONSUMER_CREATED /
CONSUMER_CLOSED* notification messages. Is it possible to set it? I need this
property to identify the {*}ConsumerId{*}. This property was available in the
Advisory Message but it does not seem to be part of the Notification Message.
Please let me know if I should log a separate issues for it.
Thank you!
> _AMQ_Client_ID on SESSION_CLOSED notification is always null
>
>
> Key: ARTEMIS-2824
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2824
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Tim Daly
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a JMS client with a clientId set closes the session a notification
> (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID
> is always set to null. The JMS Client Id has been verified as being set via
> the web UI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720970#comment-17720970 ] Liviu Citu commented on ARTEMIS-2824: - Then perfect! Thank you very much! > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720787#comment-17720787 ] Liviu Citu edited comment on ARTEMIS-2824 at 5/9/23 5:28 AM: - Seems good. Thank you! If not too much effort I think we will need the same change also for the initial reported notification type (SESSION_CLOSED) I would say the client id should be also set for the following notification types (at least): * SESSION_CREATED * SESSION_CLOSED Nice to have: * BINDING_REMOVED * BINDING_ADDED But again if too much effort then no need. As far as I am concerned, what you have done is sufficient. Thanks again. was (Author: JIRAUSER300236): Seems good. Thank you! If not too much effort I think we will need the same change also for the initial reported notification type (SESSION_CLOSED) I would say the client id should be also set for the following notification types (at least): * SESSION_CREATED * SESSION_CLOSED Nice to have: * BINDING_REMOVED * BINDING_ADDED But again if too much effort then no need. As far as I am concern, what you have done is sufficient. Thanks again. > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720787#comment-17720787 ] Liviu Citu edited comment on ARTEMIS-2824 at 5/9/23 5:28 AM: - Seems good. Thank you! If not too much effort I think we will need the same change also for the initial reported notification type (SESSION_CLOSED) I would say the client id should be also set for the following notification types (at least): * SESSION_CREATED * SESSION_CLOSED Nice to have: * BINDING_REMOVED * BINDING_ADDED But again if too much effort then no need. As far as I am concern, what you have done is sufficient. Thanks again. was (Author: JIRAUSER300236): Seems good. Thank you! > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720787#comment-17720787 ] Liviu Citu commented on ARTEMIS-2824: - Seems good. Thank you! > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[
https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720608#comment-17720608
]
Liviu Citu commented on ARTEMIS-2824:
-
We were using advisory messages for service discovery in such a way that when a
server is up it will create a connection with a specific client ID (which is
{*}ServerName{*}). Server will then create a consumer (main) on a specific hear
beat topic (topic shared by other servers as well) so that this will trigger a
notification message. On the application (client) side, we listen to
notification messages and when we receive a consumer create/close message we
need to know which server went up or down. However, currently it is impossible
to tell this because we are missing in the notification message the client ID
information about the consumer (as we had in case of advisory message).
> _AMQ_Client_ID on SESSION_CLOSED notification is always null
>
>
> Key: ARTEMIS-2824
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2824
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Tim Daly
>Assignee: Justin Bertram
>Priority: Major
>
> When a JMS client with a clientId set closes the session a notification
> (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID
> is always set to null. The JMS Client Id has been verified as being set via
> the web UI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
