I've encounter a problem where our WebSocket connections to ActiveMQ 5.13.3 are terminated abruptly. I thought, I might use WireShark to inspect the TCP layer for clues why the connection may be corrupted, but I'm not sure the ActiveMQ uses TCP protocol as its transport layer protocol for sending the messages.
All the kinds of clients and protocols which ActiveMQ supports use TCP as their transport layer. WebSockets specifically use TCP.
ActiveMQ Broker supports many transport layer protocols, including TCP.
References:
If you are using ActiveMQ Classic:
https://activemq.apache.org/components/classic/
If you are using ActiveMQ Artemis:
https://activemq.apache.org/components/artemis/
Related
I set up ActiveMQ Artemis consumer using spring-boot-starter-artemis and JMS. I also launched broker locally and I aim to configure these to communicate over OpenWire protocol. To constrain communication to that protocol I modified acceptor in broker.xml (protocols=OPENWIRE). It looks like that:
<acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;supportAdvisory=false;suppressInternalManagementObjects=false</acceptor>
However, unfortunately I'm getting the following error:
org.springframework.jms.UncategorizedJmsException: Uncategorized exception occurred during JMS processing; nested exception is javax.jms.JMSException: Failed to create session factory; nested exception is ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ219013: Timed out waiting to receive cluster topology. Group:null]
How can I configure the client to use OpenWire protocol?
What is the default protocol they communicate on? Before I constrained the communication, Artemis Console was presenting the connection has been established on CORE protocol, which as far as I understand collective protocol. Which one i target protocol they really communicate on and how can I check this out?
The reason you're receiving ActiveMQConnectionTimedOutException is because you trying to use spring-boot-starter-artemis to connect to an acceptor which is configured to only support the OpenWire protocol. This will never work because spring-boot-starter-artemis depends on artemis-jms-client which will only use the ActiveMQ Artemis "core" protocol, not OpenWire.
You should configure the acceptor in broker.xml to support core, e.g.:
protocols=CORE,OPENWIRE
If you want the client to use OpenWire then you need to use the OpenWire JMS client library from ActiveMQ "Classic."
I was following the https://docs.spring.io/spring-boot/docs/2.0.0.M3/reference/html/boot-features-messaging.html#boot-features-artemis guide.
With Core protocol with JMS, app is able to send message to Artemis broker.
spring.artemis.mode=native
spring.artemis.host=<broker host>
spring.artemis.port=61616
spring.artemis.user=admin
spring.artemis.password=<password>
When I switched to AMQP protocol with 5672 port, I am getting below error.
spring.artemis.mode=native
spring.artemis.host=<broker host>
spring.artemis.port=5672
spring.artemis.user=admin
spring.artemis.password=<password>
Caused by: org.apache.activemq.artemis.api.core.ActiveMQConnectionTimedOutException: AMQ219013: Timed out waiting to receive cluster topology. Group:null
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:712) ~[artemis-core-client-2.12.0.jar:2.12.0]
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:884) ~[artemis-jms-client-2.12.0.jar:2.12.0]
... 68 common frames omitted
what changes I have to make along to enable transition over AMQP protocol in my spring boot app? Thanks.
In order to use the AMQP protocol you'd need to somehow force Spring to use the Qpid JMS client implementation rather than ActiveMQ Artemis' core JMS client implementation, but I don't believe that is possible.
It's my understanding that the MassTransit in-memory transport only supports endpoints within the same process. Assuming that's accurate, is there an IPC transport available? If not, is there any documentation on how to go about implementing a custom transport?
There are no interprocess communication transports for MassTransit, the transport all use a message broker (such as RabbitMQ, ActiveMQ, etc.).
There isn't specific guidance on how to create your own transport, the only suggestion is to use an existing transport (such as the in-memory one) to build a new transport for IPC (if that's what you want).
In IoT scenario a lot of standard force pushing packets to mqtt queues over UDP protocol. This scenario become more and more frequent day by day, and for this reason now we have a new kind of mqtt queues named mqtt-sn.
In spring-integration-mqtt I'm using a paho client, however this has a specific client implementation ready to use mqtt-sn (https://eclipse.org/paho/clients/c/embedded-sn/) and there is also an implementation of moquitto over mqtt-sn (https://github.com/eclipse/mosquitto.rsmb).
There is any way to for spring-integration-mqtt over UDP protocol or there is an implementation which allow to use mqtt-sn over spring-integration?
Most (if not all) MQTT-SN broker bridge the messages to MQTT topics so just use the normal Spring/MQTT integration with a suitable broker.
I have a scenario , where i have my sender code written in Node.js which uses STOMP protocol to publish it to the destination(queue) and the receiver code written in java which use TCP protocol to receive the message from the destination(queue) through ActiveMQ server.Will it be possible for the clients(sender/receiver) to communicate? or it should be the same protocol at either end?
The ActiveMQ documentation covers this on the Stomp page (http://activemq.apache.org/stomp.html) in the paragraphs
Working with JMS Text/Bytes Messages and Stomp
Message transformations
Stomp extensions for JMS message semantics
ActiveMQ extensions to Stomp
ActiveMQ supports richt message conversion between messages from different protocols. Not all multi-protocol have this feature, for example ActiveMQ Apollo (issue 267).
Not an issue. ActiveMQ acts as a multiprotocol message exchange so messages received by the broker in any supported protocol can in turn be sent to receivers in any other supported protocol.