My use case warrants the use of a publish-subscribe model, so I'm using topics that are defined in my Spring Boot client. I've used the tool MQTT.fx and two Spring Boot clients to test things. The two Spring Boot clients are able to communicate with each other, but the MQTT.fx client only connects to the broker and does not produce or consume messages. The two Spring Boot clients both connect to port 61616, and the MQTT.fx client connects to port 1883.
For my project, I need to get the MQTT.fx client working as it is highly representative of the microcontroller that is intended to work with the server. Failure on MQTT.fx is failure on the microcontroller.
The acceptor configuration in my broker.xml file is as show below.
<acceptors>
<!-- Acceptor for every supported protocol -->
<acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;supportAdvisory=false;suppressInternalManagementObjects=false</acceptor>
<!-- AMQP Acceptor. Listens on default AMQP port for AMQP traffic.-->
<acceptor name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpMinLargeMessageSize=102400;amqpDuplicateDetection=true</acceptor>
<!-- STOMP Acceptor. -->
<acceptor name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true</acceptor>
<!-- HornetQ Compatibility Acceptor. Enables HornetQ Core and STOMP for legacy HornetQ clients. -->
<acceptor name="hornetq">tcp://0.0.0.0:5445?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true</acceptor>
<!-- MQTT Acceptor -->
<acceptor name="mqtt">tcp://0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT;useEpoll=true</acceptor>
</acceptors>
The logs when the Spring Boot clients communicate are as below. First, a message is sent to the topic server.weatherForecast, and consequently, after some processing, a response is sent to AMEBAA000105.device.weatherForecast.
2021-10-04 14:14:04,860 [AUDIT](Thread-8 (activemq-netty-threads))
AMQ601715: User admin(admins)#127.0.0.1:1125 successfully authenticated
2021-10-04 14:14:04,860 [AUDIT](Thread-8 (activemq-netty-threads)) AMQ601267: User admin(admins)#127.0.0.1:1125 is creating a core session on target resource ActiveMQServerImpl::name=0.0.0.0 [with parameters: [3b141c41-24ef-11ec-aa52-00155d831300, null, ****, 102400, RemotingConnectionImpl [ID=6280c69f, clientID=null, nodeID=b719c384-1d0a-11ec-8b7c-00155d831300, transportConnection=org.apache.activemq.artemis.core.remoting.impl.netty.NettyServerConnection#417b6fef[ID=6280c69f, local= /127.0.0.1:61616, remote=/127.0.0.1:1125]], true, true, false, false, null, org.apache.activemq.artemis.core.protocol.core.impl.CoreSessionCallback#103d417f, true, OperationContextImpl [61828916] [minimalStore=9223372036854775807, storeLineUp=0, stored=0, minimalReplicated=9223372036854775807, replicationLineUp=0, replicated=0, paged=0, minimalPage=9223372036854775807, pageLineUp=0, errorCode=-1, errorMessage=null, executorsPending=0, executor=OrderedExecutor(tasks=[])], {}]]
2021-10-04 14:14:04,864 [AUDIT](Thread-7 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6#b62d79)) AMQ601500: User admin(admins)#127.0.0.1:1125 is sending a message CoreMessage[messageID=528267,durable=true,userID=3b146a62-24ef-11ec-aa52-00155d831300,priority=4, timestamp=Mon Oct 04 14:14:04 IST 2021,expiration=0, durable=true, address=jms.topic.server.weatherForecast,size=314,properties=TypedProperties[__AMQ_CID=3b13ce1f-24ef-11ec-aa52-00155d831300]]#1994364957, with Context: RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null previousRoute:null, reusable=null, version=0)
..................................................
2021-10-04 14:14:04,865 [AUDIT](Thread-7 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6#b62d79)) AMQ601501: User admin(admins)#127.0.0.1:1110 is consuming a message from 41207748-6ed3-42d2-b75e-044805212686: Reference[528267]:RELIABLE:CoreMessage[messageID=528267,durable=true,userID=3b146a62-24ef-11ec-aa52-00155d831300,priority=4, timestamp=Mon Oct 04 14:14:04 IST 2021,expiration=0, durable=true, address=jms.topic.server.weatherForecast,size=314,properties=TypedProperties[__AMQ_CID=3b13ce1f-24ef-11ec-aa52-00155d831300]]#1994364957
2021-10-04 14:14:04,868 [AUDIT](Thread-4 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6#b62d79)) AMQ601502: User admin(admins)#127.0.0.1:1110 is acknowledging a message from 41207748-6ed3-42d2-b75e-044805212686: CoreMessage[messageID=528267,durable=true,userID=3b146a62-24ef-11ec-aa52-00155d831300,priority=4, timestamp=Mon Oct 04 14:14:04 IST 2021,expiration=0, durable=true, address=jms.topic.server.weatherForecast,size=314,properties=TypedProperties[__AMQ_CID=3b13ce1f-24ef-11ec-aa52-00155d831300]]#1994364957
2021-10-04 14:14:08,059 [AUDIT](Thread-8 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6#b62d79)) AMQ601500: User admin(admins)#127.0.0.1:1110 is sending a message CoreMessage[messageID=528349,durable=true,userID=3cfc1623-24ef-11ec-aa52-00155d831300,priority=4, timestamp=Mon Oct 04 14:14:08 IST 2021,expiration=0, durable=true, address=null,size=190,properties=TypedProperties[__AMQ_CID=d04d0e87-24ee-11ec-aa52-00155d831300]]#600964226, with Context: RoutingContextImpl(Address=jms.topic.AMEBAA000105.device.weatherForecast, routingType=null, PreviousAddress=jms.topic.AMEBAA000105.device.weatherForecast previousRoute:null, reusable=null, version=0)
..................................................
The logs when using MQTT.fx are as below. Initially AMEBAA000105.device.weatherForecast is subscribed to, and then a message is sent to server.weatherForecast. The Spring Boot client meant to receive these messages does not receive anything, and consequently does not send anything to AMEBAA000105.device.weatherForecast. When the publication of a message to AMEBAA000105.device.weatherForecast from the Spring Boot client is triggered by another Spring Boot client, MQTT.fx does not capture the message.
2021-10-04 14:24:35,443 [AUDIT](Thread-17 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6#b62d79)) AMQ601265: User admin(admins)#192.168.0.107:18640 is creating a core consumer on target resource ServerSessionImpl() [with parameters: [534062, MQTT_FX_Client.AMEBAA000105.device.weatherForecast, null, 0, false, false, -1]]
2021-10-04 14:24:43,719 [AUDIT](Thread-10 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6#b62d79)) AMQ601500: User admin(admins)#192.168.0.107:18640 is sending a message CoreMessage[messageID=534380,durable=false,userID=null,priority=0, timestamp=0,expiration=0, durable=false, address=server.weatherForecast,size=200,properties=TypedProperties[mqtt.message.retain=false,mqtt.qos.level=0]]#1214406991, with Context: RoutingContextImpl(Address=server.weatherForecast, routingType=null, PreviousAddress=null previousRoute:null, reusable=null, version=0)
The above logs are the audit logs. In the artemis.log file, MQTT.fx keeps pinging the broker.
2021-10-04 14:30:43,727 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): OUT >> PINGRESP
2021-10-04 14:31:43,728 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): OUT >> PINGRESP
2021-10-04 14:32:43,729 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): OUT >> PINGRESP
2021-10-04 14:33:43,731 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): OUT >> PINGRESP
2021-10-04 14:34:43,732 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): OUT >> PINGRESP
2021-10-04 14:35:43,733 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): OUT >> PINGRESP
Logs when subscribing or publishing from MQTT.fx in the artemis.log file are as below
2021-10-04 14:22:27,702 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): IN << SUBSCRIBE(3)
AMEBAA000105.device.weatherForecast : AT_MOST_ONCE
2021-10-04 14:24:43,718 TRACE [org.apache.activemq.artemis.core.protocol.mqtt] MQTT(MQTT_FX_Client): IN << PUBLISH(-1) topic=server.weatherForecast, qos=AT_MOST_ONCE, retain=false, dup=false, payload={"serialNumber" : "AMEBAA000105"}
Any help is much appreciated.
You say that when you're testing the Spring Boot clients you send a message to server.weatherForecast and the after some processing a response is sent to AMEBAA000105.device.weatherForecast. However, that is not what the logs show. The logs indicate that you send a message to jms.topic.server.weatherForecast and jms.topic.AMEBAA000105.device.weatherForecast respectively. Notice the jms.topic. prefix.
I believe this is the root of your problem because according to the logs the MQTT actually will use server.weatherForecast and AMEBAA000105.device.weatherForecast. Since the two clients aren't using matching names then they can never work together with your current configuration.
My guess is that you're using a legacy Artemis 1.x client from your Spring Boot applications and that is why the jms.topic. prefix is being used. You should either move to a newer client (e.g. one that matches the broker version you're using) or configure the anycastPrefix and multicastPrefix to support the legacy 1.x client. The default broker.xml has a comment which explains how to do this:
<!-- Note: If an acceptor needs to be compatible with HornetQ and/or Artemis 1.x clients add
"anycastPrefix=jms.queue.;multicastPrefix=jms.topic." to the acceptor url.
See https://issues.apache.org/jira/browse/ARTEMIS-1644 for more information. -->
This comment appears in the acceptors block by default, but it looks like you removed it since it's not in the XML you pasted.
If you want to confirm which library the client is using the simplest way to to find out is simply to inspect the client's environment. However, if that doesn't work and you have access to the broker logs then you can enable TRACE logging for org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl and then look at the version passed in the CreateSessionMessage. If it's < 131 then it's not a 2.18.0 client.
Changing the signature of consumeWeatherForecastRequest method to private void consumeWeatherForecastRequest(String incomingMessage) should fix your issue.
We have a Mule Service running on a server. I am developing a stand alone Mule Client that connects directly into the Mule service.
When I run the client, I am receiving the below error:
ERROR 2015-09-23 10:36:02,724 [[cheetah-web-services].connector.http.mule.default.receiver.03] org.mule.exception.DefaultMessagingExceptionStrategy:
********************************************************************************
Message : Failed to transform from "byte[]" to "Object"
Type : org.mule.api.transformer.TransformerException
Code : MULE_ERROR-109
JavaDoc : http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transformer/TransformerException.html
Transformer : ByteArrayToMuleMessage{this=1574dd9, name='null', ignoreBadInput=false, returnClass=SimpleDataType{type=org.mule.api.MuleMessage, mimeType='*/*'}, sourceTypes=[SimpleDataType{type=[B, mimeType='*/*'}, SimpleDataType{type=java.io.InputStream, mimeType='*/*'}]}
********************************************************************************
Exception stack is:
1. com.mycompany.myapp.service.model.ServiceSearch; class invalid for deserialization (java.io.InvalidClassException)
java.io.ObjectStreamClass$ExceptionInfo:150 (null)
2. java.io.InvalidClassException: com.mycompany.myapp.service.model.ServiceSearch; class invalid for deserialization (org.apache.commons.lang.SerializationException)
org.mule.util.SerializationUtils:85 (null)
3. Failed to transform from "byte[]" to "Object" (org.mule.api.transformer.TransformerException)
org.mule.transformer.simple.ByteArrayToSerializable:54 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transformer/TransformerException.html)
********************************************************************************
Root Exception stack trace:
java.io.InvalidClassException: com.mycompany.myapp.service.model.ServiceSearch; class invalid for deserialization
I have setup a remote dispatcher agent on the server.
<client:remote-dispatcher-agent>
<client:remote-endpoint address="http://localhost:20809" exchange-pattern="request-response" responseTimeout="10000"/>
I have created a separate mule client.
<client:remote-dispatcher-agent>
<client:remote-endpoint ref="remoteDispatcherChannel" />
<client:xml-wire-format/>
</client:remote-dispatcher-agent>
<http:endpoint name="remoteDispatcherChannel"
host="localhost"
port="20809"
path="_remoting"
exchange-pattern="request-response" />
Below is the Client Code. The ServiceSearch object implements all Serializable.
MuleClient muleClient = new MuleClient(true);
RemoteDispatcher dispatcher2 = muleClient.getRemoteDispatcher("http://127.0.0.1:20809/_remoting");
MuleMessage result = dispatcher2.sendToRemoteComponent("myAppServiceDelegate", ServiceSearch, msgMap);
Below is the Mule Service flow on the server I am trying to get into. I am coming in on the invoker step. I choice this step as I could sent the object directly to the service in the required format
<flow name="post:/service/search:my-web-services-config" initialState="started">
<logger level="INFO" doc:name="Log Request Properties" message="Request Type: #[message.inboundProperties.'http.method'], Request Path: #[message.inboundProperties.'http.request.path'], Request Params: #[message.inboundProperties.'http.query.params']" />
<json:json-to-object-transformer returnClass="com.mycompany.myapp.service.model.ServiceSearch" ignoreBadInput="true" mimeType="application/json" doc:name="Request JSON to ServiceSearch" />
<invoke object-ref="myappServiceDelegate" method="processSearch" methodArguments="#[payload],#[flowVars.'CLIENT_ID']" doc:name="Calling Search Delegate" />
<logger message="Generated DSL: #[payload.queryDSL]" level="INFO" doc:name="Log Query DSL" />
<flow-ref name="BigDataSearchFlow" doc:name="Big Data Flow" />
<exception-strategy ref="globalResponseExceptionStrategy" doc:name="Reference Exception Strategy" />
</flow>
I would appreciate some feedback on this approach and suggestions on what I should look for in the ServiceSearch object.
Russ
You are using an order/newer version of com.mycompany.myapp.service.model.ServiceSearch or none at all at the server side.
Please make sure both ends do have the very same version of the file.
I have a Java service that uses Spring and CXF. The code is from a previous developer and I'm providing maintenance, but I'm seeing this in the logs
--------------------------------------
Apr 16, 2013 1:44:11 PM org.apache.cxf.interceptor.AbstractLoggingInterceptor log
INFO: Inbound Message
----------------------------
ID: 33
Address: /MyApplication/endpoint
Encoding: UTF-8
Http-Method: POST
Content-Type: application/x-www-form-urlencoded
Headers: {content-type=[application/x-www-form-urlencoded], connection=[close], host= [localhost:8080], Content-Length=[11504], user-agent=[Apache-HttpClient/4.2.3 (java 1.5)], Content-Type=[application/x-www-form-urlencoded]}
Payload: {
"events" :
[ { event }, { event }, ... ]
}
And we have too many events, and the log is becoming unmanageable. Is there a way I can turn off this logging? These log calls are not created from inside the app, they are created by some kind of interceptor which I can't find. I did find this in the cxf-context.xml config file:
<cxf:bus>
<cxf:features>
<cxf:logging />
</cxf:features>
</cxf:bus>
But the logging still appears after I already commented these lines out of the config file.
Please help. Thanks
Since the application uses log4j, turn the 'org.apache.cxf' Logger level to ERROR. Add this line to log4j.properties:
log4j.logger.org.apache.cxf=ERROR
while implementing a SSL-secured WebService with Apache CXF v2.7.3 I wanted to test how a custom exception class (e.g. MyException) is handled by the client.
Therefore I have the following server-side method:
#WebMethod
public void foo() throws MyException {
throw new MyException("test!");
}
I have also configured to log in- and outgoing messages in the cxf.xml via:
<bean id="logInbound" class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
<bean id="logOutbound" class="org.apache.cxf.interceptor.LoggingOutInterceptor"/>
<jaxws:inInterceptors>
<ref bean="logInbound"/>
</jaxws:inInterceptors>
<jaxws:outInterceptors>
<ref bean="logOutbound"/>
</jaxws:outInterceptors>
Calling this function with a client results in following console-output
INFO: Inbound Message
----------------------------
ID: 1
Address: https://localhost:8443/WebApp/services/ClientService
Encoding: UTF-8
Http-Method: POST
Content-Type: text/xml; charset=UTF-8
Headers: {Accept=[*/*], cache-control=[no-cache], connection=[keep-alive], Content-Length=[184], content-type=[text/xml; charset=UTF-8], host=[localhost:8443], pragma=[no-cache], SOAPAction=[""], user-agent=[Apache CXF 2.7.3]}
Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:foo xmlns:ns2="http://services.client.test.cloud.org/"/></soap:Body></soap:Envelope>
--------------------------------------
18.02.2013 22:49:02 org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging
INFO: Application {http://services.client.test.cloud.org/}ClientService#{http://services.client.test.cloud.org/}foo has thrown exception, unwinding now: org.cloud.test.client.exception.MyException: test!
18.02.2013 22:49:02 org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging
INFO: Application {http://services.client.test.cloud.org/}ClientService#{http://services.client.test.cloud.org/}foo has thrown exception, unwinding now: java.lang.NullPointerException: null
The client gets a "Error reading XMLStreamReader." due to a "Unexpected EOF". I guess, that no response is written by the server. Do you know why 2 exceptions are thrown and why there isn't any response to the client?
I already searched for exceptions not redirected to the client in Apache CXF-applications, but could not find any solution.
Thanks in advance!