You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Liviu Citu (Jira)" <ji...@apache.org> on 2024/06/20 06:45:00 UTC
[jira] [Updated] (AMQCPP-754) CMS exception: OpenWireFormatNegotiator::onewayWire format negotiation timeout: peer did not send his wire format.
[ https://issues.apache.org/jira/browse/AMQCPP-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Liviu Citu updated AMQCPP-754:
------------------------------
Description:
We are currently in process of migrating our JMS Broker from Classic AMQ 5.x to Artemis.
We are currently using CMS C++ client for connecting to JMS Broker. Everything works fine when using non-SSL setup (on both Windows and Linux) but we have some issues when using SSL on Linux (SSL on Windows is OK).
The initial problem started with the following exceptions on the client side:
*_024-02-22 09:54:37.377 [ERROR] [activemq_connection.cc:336] CMS exception: Channel was inactive for too long:_*
*_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1293_*
*_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1371_*
*_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 573_*
while on the JMS Broker side we had:
*_2024-03-20 12:29:08,700 ERROR [org.apache.activemq.artemis.core.server] AMQ224088: Timeout (10 seconds) on acceptor "netty-ssl-acceptor" during protocol handshake with /10.21.70.53:33053 has occurred._*
To bypass these we have added the following setting to the *broker.xml* *netty-ssl-acceptor* acceptor: *handshake-timeout=0*
However now the exceptions we are receiving are:
*_2024-05-22 09:26:40.842 [ERROR] [activemq_connection.cc:348] CMS exception: OpenWireFormatNegotiator::onewayWire format negotiation timeout: peer did not send his wire format._*
*_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1293_*
*_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1371_*
*_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 573_*
The problem replicates with the following:
* SSL on Linux problem does not replicate if non-SSL configuration is used. Also does not replicate on Windows (regardless if SSL or non-SSL is used)
* two Artemis JMS Broker instances running on the same Linux host (problem does not replicate if there is only one Artemis JMS Broker instance running)
* problem also replicates if there is one Artemis and one Classic AMQ instance running on the same host
*
* CMS C++ client is also on Linux running on the same host. Basically both client and server are running on the same host
* there are many connections done in the same time to the broker (50+). If there are only few then the problem does not happen
* example of JMS Broker URL used by the client (the other instance just uses a different port)
*ssl://host_aname:3177?soKeepAlive=true&wireFormat.MaxInactivityDuration=0*
* one JMS Broker configuration file (attached, just mangled the password). The other one is similar (port changed)
Does Artemis support non-UTF-8 encoding? Do we need now to encode all messages to UTF-8 before sending them to the server? Similarly to decode them upon receiving?
This will cause some problems on our end because:
* we have many clients already using the ActiveMQ classic and migrating them to Artemis will cause issues when migrating KahaDB to Artemis because all the messages have to be encoded to UTF-8 otherwise they will not work in Artemis
* encoding/decoding every message will impact the overall performance. We have applications handling thousands of messages every day and conversion of these messages will increase the time spent during communication with JMS broker
was:
When a text message non-UTF-8 (ISO-8859-15) containing special characters is sent from ActiveMQ CPP client to Artemis, an exception "java.io.UTFDataFormatException" is seen in Artemis server log.
Although the exception is thrown as a warning, the message gets rejected by the server.
Below the Artemis server log:
{noformat}
2023-09-29 11:34:32,736 WARN [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors occurred during the buffering operation
java.io.UTFDataFormatException: null
at org.apache.activemq.util.MarshallingSupport.convertUTF8WithBuf(MarshallingSupport.java:386) ~[activemq-client-5.17.2.jar:5.17.2]
at org.apache.activemq.util.MarshallingSupport.readUTF8(MarshallingSupport.java:358) ~[activemq-client-5.17.2.jar:5.17.2]
at org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.writeTextType(OpenWireMessageConverter.java:233) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at org.apache.activemq.artemis.core.protocol.openwire.OpenWireMessageConverter.inbound(OpenWireMessageConverter.java:128) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at org.apache.activemq.artemis.core.protocol.openwire.amq.AMQSession.send(AMQSession.java:376) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1671) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769) ~[activemq-client-5.17.2.jar:5.17.2]
at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.30.0.jar:?]
2023-09-29 11:34:32,753 WARN [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors occurred during the buffering operation
org.apache.activemq.artemis.api.core.ActiveMQException: null
at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processMessage(OpenWireConnection.java:1674) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:769) ~[activemq-client-5.17.2.jar:5.17.2]
at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:369) ~[artemis-openwire-protocol-2.30.0.jar:2.30.0]
at org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32) ~[artemis-commons-2.30.0.jar:?]
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.30.0.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.30.0.jar:?]
2023-09-29 11:34:32,755 WARN [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors occurred during the buffering operation
java.io.UTFDataFormatException: null
{noformat}
Just create a small test program using ActiveMQ CPP and send a message to Artemis containing a french or german specific character.
I have found an old discussion from ActiveMQ Community but it was focused on ActiveMQ CPP rather on Artemis.
[https://lists.apache.org/thread/vywv1gk32mkhvj7sghnvlf7ng5zb1obp]
This is a regression compared with ActiveMQ Classic which does not have this issue.
Does Artemis support non-UTF-8 encoding? Do we need now to encode all messages to UTF-8 before sending them to the server? Similarly to decode them upon receiving?
This will cause some problems on our end because:
* we have many clients already using the ActiveMQ classic and migrating them to Artemis will cause issues when migrating KahaDB to Artemis because all the messages have to be encoded to UTF-8 otherwise they will not work in Artemis
* encoding/decoding every message will impact the overall performance. We have applications handling thousands of messages every day and conversion of these messages will increase the time spent during communication with JMS broker
> CMS exception: OpenWireFormatNegotiator::onewayWire format negotiation timeout: peer did not send his wire format.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: AMQCPP-754
> URL: https://issues.apache.org/jira/browse/AMQCPP-754
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Reporter: Liviu Citu
> Priority: Major
>
> We are currently in process of migrating our JMS Broker from Classic AMQ 5.x to Artemis.
> We are currently using CMS C++ client for connecting to JMS Broker. Everything works fine when using non-SSL setup (on both Windows and Linux) but we have some issues when using SSL on Linux (SSL on Windows is OK).
> The initial problem started with the following exceptions on the client side:
> *_024-02-22 09:54:37.377 [ERROR] [activemq_connection.cc:336] CMS exception: Channel was inactive for too long:_*
> *_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1293_*
> *_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1371_*
> *_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 573_*
> while on the JMS Broker side we had:
> *_2024-03-20 12:29:08,700 ERROR [org.apache.activemq.artemis.core.server] AMQ224088: Timeout (10 seconds) on acceptor "netty-ssl-acceptor" during protocol handshake with /10.21.70.53:33053 has occurred._*
> To bypass these we have added the following setting to the *broker.xml* *netty-ssl-acceptor* acceptor: *handshake-timeout=0*
> However now the exceptions we are receiving are:
> *_2024-05-22 09:26:40.842 [ERROR] [activemq_connection.cc:348] CMS exception: OpenWireFormatNegotiator::onewayWire format negotiation timeout: peer did not send his wire format._*
> *_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1293_*
> *_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 1371_*
> *_FILE: activemq/core/ActiveMQConnection.cpp, LINE: 573_*
> The problem replicates with the following:
> * SSL on Linux problem does not replicate if non-SSL configuration is used. Also does not replicate on Windows (regardless if SSL or non-SSL is used)
> * two Artemis JMS Broker instances running on the same Linux host (problem does not replicate if there is only one Artemis JMS Broker instance running)
> * problem also replicates if there is one Artemis and one Classic AMQ instance running on the same host
> *
> * CMS C++ client is also on Linux running on the same host. Basically both client and server are running on the same host
> * there are many connections done in the same time to the broker (50+). If there are only few then the problem does not happen
> * example of JMS Broker URL used by the client (the other instance just uses a different port)
> *ssl://host_aname:3177?soKeepAlive=true&wireFormat.MaxInactivityDuration=0*
> * one JMS Broker configuration file (attached, just mangled the password). The other one is similar (port changed)
>
> Does Artemis support non-UTF-8 encoding? Do we need now to encode all messages to UTF-8 before sending them to the server? Similarly to decode them upon receiving?
> This will cause some problems on our end because:
> * we have many clients already using the ActiveMQ classic and migrating them to Artemis will cause issues when migrating KahaDB to Artemis because all the messages have to be encoded to UTF-8 otherwise they will not work in Artemis
> * encoding/decoding every message will impact the overall performance. We have applications handling thousands of messages every day and conversion of these messages will increase the time spent during communication with JMS broker
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@activemq.apache.org
For additional commands, e-mail: issues-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact