Plugin denying writing to certain topic, yet client still reports success

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Plugin denying writing to certain topic, yet client still reports success

Jędrzej Dudkiewicz
I wrote simple authenticating/authorizing plugin that reads CN field
in certificate passed by the client and decides which topic/queue can
be created/written to/read from by that client. It works but I have
two issues, one described here and the other one being this:
http://activemq.2283324.n4.nabble.com/Authorization-plugin-don-t-know-what-to-do-with-client-attempting-to-write-to-weird-advisory-topic-tp4752509.html
(maybe I should somehow migrate it here?).

I wrote my plugin using
org.apache.activemq.security.AuthorizationBroker as a reference. I
extend BrokerFilter class and override i.a. "send()" method. If access
check fails (so client can't send messages to this destination), I
throw SecurityException, just like AuthorizationBroker. This works
flawlessly If I use OpenWire client (written in Java in 50 lines or
so). Sending message to the destination that I have no access to
results in client error and even exception detailing what went wrong
contains message from exception thrown by my plugin.

My problem is that similar client that uses paho.mqtt.cpp library
(built upon paho.mqtt.c library) reports that everything went well. I
also tried using mosquitto_pub to the same effect. Output of
mosquitto_pub execution is below:

jd@gojira:~/queues/client/testclient$ cat MOSPUB.sh
mosquitto_pub --key cli01.key \
        --cert cli01.pem --cafile test-root-ca.crt \
        -h localhost -p 1883 -t hello -m napis -d -q 2
jd@gojira:~/queues/client/testclient$ bash MOSPUB.sh
Enter PEM pass phrase:
Client mosqpub/14778-gojira sending CONNECT
Client mosqpub/14778-gojira received CONNACK
Client mosqpub/14778-gojira sending PUBLISH (d0, q2, r0, m1, 'hello',
... (5 bytes))
Client mosqpub/14778-gojira received PUBREC (Mid: 1)
Client mosqpub/14778-gojira sending PUBREL (Mid: 1)
Client mosqpub/14778-gojira received PUBCOMP (Mid: 1)
Client mosqpub/14778-gojira sending DISCONNECT

Logs from ActiveMQ look like this (most of INFO log entries are
produced by my plugin):

TRACE | TCP consumer thread for ssl:///0:0:0:0:0:0:0:1:52520 starting
DEBUG | MQTT Client mosqpub/14788-gojira requests heart beat of 60000 ms
DEBUG | MQTT Client mosqpub/14788-gojira established heart beat of
60000 ms (60000 ms + 30000 ms grace period)
 INFO | add conn: class org.apache.activemq.broker.ConnectionContext null
 INFO | add destination:
org.apache.activemq.broker.ConnectionContext@5b0c4682
destinationtopic://ActiveMQ.Advisory.Connection tempfalse
DEBUG | MQTT Using subscription strategy: mqtt-default-subscriptions
DEBUG | MQTT Client mosqpub/14788-gojira connected. (version: 3)
TRACE | MQTT Rcv PUBLISH message:1 client:mosqpub/14788-gojira
connection:ID:gojira-33277-1569362891935-3:5
TRACE | MQTT-->ActiveMQ: MQTT_MSGID:1 client:mosqpub/14788-gojira
connection:ID:gojira-33277-1569362891935-3:5
ActiveMQ_MSGID:ID:gojira-33277-1569362891935-3:5:-1:1:1
 INFO | **************************** SEND
 INFO | SENDING TO: hello topic://hello
 INFO | CASC: CAN WRITE: zs.leaf.P-00666 hello
 INFO | CASC: CAN'T WRITE AND NOT SERVICE. ACCESS DENIED.
 WARN | Security Error occurred on connection to:
tcp://0:0:0:0:0:0:0:1:52520, User zs.leaf.P-00666 can't write to
topic://hello
 WARN | Failed to send MQTT Publish:
TRACE | Error trace: {}
java.lang.SecurityException: User zs.leaf.P-00666 can't write to topic://hello
    at zs.comm.amq.auth.CertAuthPlugin.send(CertAuthPlugin.java:124)[auth-0.0.1-SNAPSHOT.jar:]
    at org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.10.jar:5.15.10]
    at org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:578)[activemq-broker-5.15.10.jar:5.15.10]
    at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:768)[activemq-client-5.15.10.jar:5.15.10]
    at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:336)[activemq-broker-5.15.10.jar:5.15.10]
    at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:200)[activemq-broker-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45)[activemq-client-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.mqtt.MQTTInactivityMonitor.onCommand(MQTTInactivityMonitor.java:162)[activemq-mqtt-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.mqtt.MQTTTransportFilter.sendToActiveMQ(MQTTTransportFilter.java:106)[activemq-mqtt-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.mqtt.MQTTProtocolConverter.sendToActiveMQ(MQTTProtocolConverter.java:181)[activemq-mqtt-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTPublish(MQTTProtocolConverter.java:494)[activemq-mqtt-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTCommand(MQTTProtocolConverter.java:219)[activemq-mqtt-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.mqtt.MQTTTransportFilter.onCommand(MQTTTransportFilter.java:94)[activemq-mqtt-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.tcp.SslTransport.doConsume(SslTransport.java:171)[activemq-client-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)[activemq-client-5.15.10.jar:5.15.10]
    at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)[activemq-client-5.15.10.jar:5.15.10]
    at java.lang.Thread.run(Thread.java:748)[:1.8.0_222]
TRACE | MQTT Snd PUBREC message:1 client:mosqpub/14788-gojira
connection:ID:gojira-33277-1569362891935-3:5
DEBUG | MQTT Client mosqpub/14788-gojira disconnecting
 INFO | REMOVING CONNECTION:
org.apache.activemq.broker.ConnectionContext@5b0c4682
    ConnectionInfo {commandId = 0, responseRequired = true,
connectionId = ID:gojira-33277-1569362891935-3:5, clientId =
mosqpub/14788-gojira, clientIp = tcp://0:0:0:0:0:0:0:1:52520, userName
= null, password = *****, brokerPath = null, brokerMasterConnector =
false, manageable = false, clientMaster = true, faultTolerant = false,
failoverReconnect = false}
    null
 INFO | add destination:
org.apache.activemq.broker.ConnectionContext@5b0c4682
destinationtopic://ActiveMQ.Advisory.Connection tempfalse
DEBUG | Stopping transport ssl:///0:0:0:0:0:0:0:1:52520
TRACE | Closing socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]]
DEBUG | Closed socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]]


And of course message is not sent to the "hello" topic. My client
behaves exactly the same, minus debug information on client side.

My question is: is this an inherent problem of MQTT protocol or rather
error in AMQ's implementation?

This isn't really a big problem as well-behaving clients "have nothing
to fear" during normal operation, but I can imagine that it will be a
nightmare to debug in the field.

Thanks in advance,
--
Jędrzej Dudkiewicz

I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
Reply | Threaded
Open this post in threaded view
|

Re: Plugin denying writing to certain topic, yet client still reports success

jbertram
I only have a passing familiarity with the MQTT protocol and the Paho MQTT
client so I can't provide any expertise there, but in general clients will
often "fire and forget" messages based on their quality-of-service
configuration. For example, many JMS client implementations will fire and
forget non-persistent messages. By "fire and forget" I mean that they just
send the message without listening for any kind of response from the broker
because the quality-of-service dictates that the message isn't particularly
important so if the send fails for some reason they don't really care.
Perhaps your client is doing this.

Perhaps you need to implement some kind of listener to get notified of an
exception when sending a message.


Justin

On Wed, Sep 25, 2019 at 6:54 AM Jędrzej Dudkiewicz <
[hidden email]> wrote:

> I wrote simple authenticating/authorizing plugin that reads CN field
> in certificate passed by the client and decides which topic/queue can
> be created/written to/read from by that client. It works but I have
> two issues, one described here and the other one being this:
>
> http://activemq.2283324.n4.nabble.com/Authorization-plugin-don-t-know-what-to-do-with-client-attempting-to-write-to-weird-advisory-topic-tp4752509.html
> (maybe I should somehow migrate it here?).
>
> I wrote my plugin using
> org.apache.activemq.security.AuthorizationBroker as a reference. I
> extend BrokerFilter class and override i.a. "send()" method. If access
> check fails (so client can't send messages to this destination), I
> throw SecurityException, just like AuthorizationBroker. This works
> flawlessly If I use OpenWire client (written in Java in 50 lines or
> so). Sending message to the destination that I have no access to
> results in client error and even exception detailing what went wrong
> contains message from exception thrown by my plugin.
>
> My problem is that similar client that uses paho.mqtt.cpp library
> (built upon paho.mqtt.c library) reports that everything went well. I
> also tried using mosquitto_pub to the same effect. Output of
> mosquitto_pub execution is below:
>
> jd@gojira:~/queues/client/testclient$ cat MOSPUB.sh
> mosquitto_pub --key cli01.key \
>         --cert cli01.pem --cafile test-root-ca.crt \
>         -h localhost -p 1883 -t hello -m napis -d -q 2
> jd@gojira:~/queues/client/testclient$ bash MOSPUB.sh
> Enter PEM pass phrase:
> Client mosqpub/14778-gojira sending CONNECT
> Client mosqpub/14778-gojira received CONNACK
> Client mosqpub/14778-gojira sending PUBLISH (d0, q2, r0, m1, 'hello',
> ... (5 bytes))
> Client mosqpub/14778-gojira received PUBREC (Mid: 1)
> Client mosqpub/14778-gojira sending PUBREL (Mid: 1)
> Client mosqpub/14778-gojira received PUBCOMP (Mid: 1)
> Client mosqpub/14778-gojira sending DISCONNECT
>
> Logs from ActiveMQ look like this (most of INFO log entries are
> produced by my plugin):
>
> TRACE | TCP consumer thread for ssl:///0:0:0:0:0:0:0:1:52520 starting
> DEBUG | MQTT Client mosqpub/14788-gojira requests heart beat of 60000 ms
> DEBUG | MQTT Client mosqpub/14788-gojira established heart beat of
> 60000 ms (60000 ms + 30000 ms grace period)
>  INFO | add conn: class org.apache.activemq.broker.ConnectionContext null
>  INFO | add destination:
> org.apache.activemq.broker.ConnectionContext@5b0c4682
> destinationtopic://ActiveMQ.Advisory.Connection tempfalse
> DEBUG | MQTT Using subscription strategy: mqtt-default-subscriptions
> DEBUG | MQTT Client mosqpub/14788-gojira connected. (version: 3)
> TRACE | MQTT Rcv PUBLISH message:1 client:mosqpub/14788-gojira
> connection:ID:gojira-33277-1569362891935-3:5
> TRACE | MQTT-->ActiveMQ: MQTT_MSGID:1 client:mosqpub/14788-gojira
> connection:ID:gojira-33277-1569362891935-3:5
> ActiveMQ_MSGID:ID:gojira-33277-1569362891935-3:5:-1:1:1
>  INFO | **************************** SEND
>  INFO | SENDING TO: hello topic://hello
>  INFO | CASC: CAN WRITE: zs.leaf.P-00666 hello
>  INFO | CASC: CAN'T WRITE AND NOT SERVICE. ACCESS DENIED.
>  WARN | Security Error occurred on connection to:
> tcp://0:0:0:0:0:0:0:1:52520, User zs.leaf.P-00666 can't write to
> topic://hello
>  WARN | Failed to send MQTT Publish:
> TRACE | Error trace: {}
> java.lang.SecurityException: User zs.leaf.P-00666 can't write to
> topic://hello
>     at
> zs.comm.amq.auth.CertAuthPlugin.send(CertAuthPlugin.java:124)[auth-0.0.1-SNAPSHOT.jar:]
>     at
> org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:578)[activemq-broker-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:768)[activemq-client-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:336)[activemq-broker-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:200)[activemq-broker-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45)[activemq-client-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.mqtt.MQTTInactivityMonitor.onCommand(MQTTInactivityMonitor.java:162)[activemq-mqtt-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.mqtt.MQTTTransportFilter.sendToActiveMQ(MQTTTransportFilter.java:106)[activemq-mqtt-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.mqtt.MQTTProtocolConverter.sendToActiveMQ(MQTTProtocolConverter.java:181)[activemq-mqtt-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTPublish(MQTTProtocolConverter.java:494)[activemq-mqtt-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTCommand(MQTTProtocolConverter.java:219)[activemq-mqtt-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.mqtt.MQTTTransportFilter.onCommand(MQTTTransportFilter.java:94)[activemq-mqtt-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.tcp.SslTransport.doConsume(SslTransport.java:171)[activemq-client-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)[activemq-client-5.15.10.jar:5.15.10]
>     at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)[activemq-client-5.15.10.jar:5.15.10]
>     at java.lang.Thread.run(Thread.java:748)[:1.8.0_222]
> TRACE | MQTT Snd PUBREC message:1 client:mosqpub/14788-gojira
> connection:ID:gojira-33277-1569362891935-3:5
> DEBUG | MQTT Client mosqpub/14788-gojira disconnecting
>  INFO | REMOVING CONNECTION:
> org.apache.activemq.broker.ConnectionContext@5b0c4682
>     ConnectionInfo {commandId = 0, responseRequired = true,
> connectionId = ID:gojira-33277-1569362891935-3:5, clientId =
> mosqpub/14788-gojira, clientIp = tcp://0:0:0:0:0:0:0:1:52520, userName
> = null, password = *****, brokerPath = null, brokerMasterConnector =
> false, manageable = false, clientMaster = true, faultTolerant = false,
> failoverReconnect = false}
>     null
>  INFO | add destination:
> org.apache.activemq.broker.ConnectionContext@5b0c4682
> destinationtopic://ActiveMQ.Advisory.Connection tempfalse
> DEBUG | Stopping transport ssl:///0:0:0:0:0:0:0:1:52520
> TRACE | Closing socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
> Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]]
> DEBUG | Closed socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
> Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]]
>
>
> And of course message is not sent to the "hello" topic. My client
> behaves exactly the same, minus debug information on client side.
>
> My question is: is this an inherent problem of MQTT protocol or rather
> error in AMQ's implementation?
>
> This isn't really a big problem as well-behaving clients "have nothing
> to fear" during normal operation, but I can imagine that it will be a
> nightmare to debug in the field.
>
> Thanks in advance,
> --
> Jędrzej Dudkiewicz
>
> I really hate this damn machine, I wish that they would sell it.
> It never does just what I want, but only what I tell it.
>
Reply | Threaded
Open this post in threaded view
|

Re: Plugin denying writing to certain topic, yet client still reports success

Jędrzej Dudkiewicz
On Wed, Sep 25, 2019 at 9:17 PM Justin Bertram <[hidden email]> wrote:

> I only have a passing familiarity with the MQTT protocol and the Paho MQTT

So do I, it is still less than few hours :)

>  in general clients will
> often "fire and forget" messages based on their quality-of-service
> configuration.

I used QOS = 2, which is called "at most once", which means client
should wait for response. I used 2 in both cases.

> For example, many JMS client implementations will fire and
> forget non-persistent messages. [...]
> Perhaps your client is doing this.

No, you can see in logs that message sequence from mosquitto_pub
contains PUBREC, PUBREL and PUBCOMP. According to
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
(and I believe nothing changed in later versions) these are
respectively:

Publish received - meaning that AMQ received the message.
Publish release - meaning that message can be released by the client
(if I understand it correctly)
Publish completed - meaning that message publishing ended successfully.

In fact now that I look at it there is no message that would indicate
that client is not allowed to publish.

> Perhaps you need to implement some kind of listener to get notified of an
> exception when sending a message.

I've been thinking about it, but if client isn't subscribed to any
topics (and in my case it might be not subscribed to anything) there
is no way to send any info back, except maybe forcibly closing the
connection.

And now, after reading some more on aforementioned site I found the following:

    If a Server implementation does not authorize a PUBLISH to be
performed by a Client; it has no way of informing that Client. It MUST
either make a positive acknowledgement, according to the normal QoS
rules, or close the Network Connection [MQTT-3.3.5-2].

Well duh.

Since AMQ chooses to make a positive acknowledgement instead of
closing connection, I'll try to close it myself and see what happens.

Thank you for your answer.

JD


> Justin
>
> On Wed, Sep 25, 2019 at 6:54 AM Jędrzej Dudkiewicz <
> [hidden email]> wrote:
>
> > I wrote simple authenticating/authorizing plugin that reads CN field
> > in certificate passed by the client and decides which topic/queue can
> > be created/written to/read from by that client. It works but I have
> > two issues, one described here and the other one being this:
> >
> > http://activemq.2283324.n4.nabble.com/Authorization-plugin-don-t-know-what-to-do-with-client-attempting-to-write-to-weird-advisory-topic-tp4752509.html
> > (maybe I should somehow migrate it here?).
> >
> > I wrote my plugin using
> > org.apache.activemq.security.AuthorizationBroker as a reference. I
> > extend BrokerFilter class and override i.a. "send()" method. If access
> > check fails (so client can't send messages to this destination), I
> > throw SecurityException, just like AuthorizationBroker. This works
> > flawlessly If I use OpenWire client (written in Java in 50 lines or
> > so). Sending message to the destination that I have no access to
> > results in client error and even exception detailing what went wrong
> > contains message from exception thrown by my plugin.
> >
> > My problem is that similar client that uses paho.mqtt.cpp library
> > (built upon paho.mqtt.c library) reports that everything went well. I
> > also tried using mosquitto_pub to the same effect. Output of
> > mosquitto_pub execution is below:
> >
> > jd@gojira:~/queues/client/testclient$ cat MOSPUB.sh
> > mosquitto_pub --key cli01.key \
> >         --cert cli01.pem --cafile test-root-ca.crt \
> >         -h localhost -p 1883 -t hello -m napis -d -q 2
> > jd@gojira:~/queues/client/testclient$ bash MOSPUB.sh
> > Enter PEM pass phrase:
> > Client mosqpub/14778-gojira sending CONNECT
> > Client mosqpub/14778-gojira received CONNACK
> > Client mosqpub/14778-gojira sending PUBLISH (d0, q2, r0, m1, 'hello',
> > ... (5 bytes))
> > Client mosqpub/14778-gojira received PUBREC (Mid: 1)
> > Client mosqpub/14778-gojira sending PUBREL (Mid: 1)
> > Client mosqpub/14778-gojira received PUBCOMP (Mid: 1)
> > Client mosqpub/14778-gojira sending DISCONNECT
> >
> > Logs from ActiveMQ look like this (most of INFO log entries are
> > produced by my plugin):
> >
> > TRACE | TCP consumer thread for ssl:///0:0:0:0:0:0:0:1:52520 starting
> > DEBUG | MQTT Client mosqpub/14788-gojira requests heart beat of 60000 ms
> > DEBUG | MQTT Client mosqpub/14788-gojira established heart beat of
> > 60000 ms (60000 ms + 30000 ms grace period)
> >  INFO | add conn: class org.apache.activemq.broker.ConnectionContext null
> >  INFO | add destination:
> > org.apache.activemq.broker.ConnectionContext@5b0c4682
> > destinationtopic://ActiveMQ.Advisory.Connection tempfalse
> > DEBUG | MQTT Using subscription strategy: mqtt-default-subscriptions
> > DEBUG | MQTT Client mosqpub/14788-gojira connected. (version: 3)
> > TRACE | MQTT Rcv PUBLISH message:1 client:mosqpub/14788-gojira
> > connection:ID:gojira-33277-1569362891935-3:5
> > TRACE | MQTT-->ActiveMQ: MQTT_MSGID:1 client:mosqpub/14788-gojira
> > connection:ID:gojira-33277-1569362891935-3:5
> > ActiveMQ_MSGID:ID:gojira-33277-1569362891935-3:5:-1:1:1
> >  INFO | **************************** SEND
> >  INFO | SENDING TO: hello topic://hello
> >  INFO | CASC: CAN WRITE: zs.leaf.P-00666 hello
> >  INFO | CASC: CAN'T WRITE AND NOT SERVICE. ACCESS DENIED.
> >  WARN | Security Error occurred on connection to:
> > tcp://0:0:0:0:0:0:0:1:52520, User zs.leaf.P-00666 can't write to
> > topic://hello
> >  WARN | Failed to send MQTT Publish:
> > TRACE | Error trace: {}
> > java.lang.SecurityException: User zs.leaf.P-00666 can't write to
> > topic://hello
> >     at
> > zs.comm.amq.auth.CertAuthPlugin.send(CertAuthPlugin.java:124)[auth-0.0.1-SNAPSHOT.jar:]
> >     at
> > org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:578)[activemq-broker-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:768)[activemq-client-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:336)[activemq-broker-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:200)[activemq-broker-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45)[activemq-client-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.mqtt.MQTTInactivityMonitor.onCommand(MQTTInactivityMonitor.java:162)[activemq-mqtt-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.mqtt.MQTTTransportFilter.sendToActiveMQ(MQTTTransportFilter.java:106)[activemq-mqtt-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.mqtt.MQTTProtocolConverter.sendToActiveMQ(MQTTProtocolConverter.java:181)[activemq-mqtt-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTPublish(MQTTProtocolConverter.java:494)[activemq-mqtt-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTCommand(MQTTProtocolConverter.java:219)[activemq-mqtt-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.mqtt.MQTTTransportFilter.onCommand(MQTTTransportFilter.java:94)[activemq-mqtt-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.tcp.SslTransport.doConsume(SslTransport.java:171)[activemq-client-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)[activemq-client-5.15.10.jar:5.15.10]
> >     at
> > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)[activemq-client-5.15.10.jar:5.15.10]
> >     at java.lang.Thread.run(Thread.java:748)[:1.8.0_222]
> > TRACE | MQTT Snd PUBREC message:1 client:mosqpub/14788-gojira
> > connection:ID:gojira-33277-1569362891935-3:5
> > DEBUG | MQTT Client mosqpub/14788-gojira disconnecting
> >  INFO | REMOVING CONNECTION:
> > org.apache.activemq.broker.ConnectionContext@5b0c4682
> >     ConnectionInfo {commandId = 0, responseRequired = true,
> > connectionId = ID:gojira-33277-1569362891935-3:5, clientId =
> > mosqpub/14788-gojira, clientIp = tcp://0:0:0:0:0:0:0:1:52520, userName
> > = null, password = *****, brokerPath = null, brokerMasterConnector =
> > false, manageable = false, clientMaster = true, faultTolerant = false,
> > failoverReconnect = false}
> >     null
> >  INFO | add destination:
> > org.apache.activemq.broker.ConnectionContext@5b0c4682
> > destinationtopic://ActiveMQ.Advisory.Connection tempfalse
> > DEBUG | Stopping transport ssl:///0:0:0:0:0:0:0:1:52520
> > TRACE | Closing socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
> > Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]]
> > DEBUG | Closed socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
> > Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]]
> >
> >
> > And of course message is not sent to the "hello" topic. My client
> > behaves exactly the same, minus debug information on client side.
> >
> > My question is: is this an inherent problem of MQTT protocol or rather
> > error in AMQ's implementation?
> >
> > This isn't really a big problem as well-behaving clients "have nothing
> > to fear" during normal operation, but I can imagine that it will be a
> > nightmare to debug in the field.
> >
> > Thanks in advance,
> > --
> > Jędrzej Dudkiewicz
> >
> > I really hate this damn machine, I wish that they would sell it.
> > It never does just what I want, but only what I tell it.
> >



--
Jędrzej Dudkiewicz

I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.