Shared subscription doesn't work with eclipse paho java client

[mv200580]

Environment

• OS: ubuntu 16.04
• Erlang/OTP: erts 7.3
• EMQ: 2.0.7
• Org.eclipse.paho.client.mqttv3: 1.1.0

Description

Shared subscription feature doesn't work with eclipse paho java client, while it works well with the mosquitto_pub/sub in the same environment.
The same issue with the mqtt.FX application http://mqttfx.jfx4ee.org/ (which is based on the eclipse paho actually).

There is the groovy subscriber sample in the attachment (mqtt01.groovy) to reproduce the issue.

[mv200580]

mqtt01.groovy.txt

[phanimahesh]

Can you please trace the client/user and paste the trace logs?

Use emqttd_ctl trace client <clientid> <file> to start tracing, and connect to emqttd using client id <clientid>. When done, stop tracing with emqttd_ctl trace client <clientid> off, and attach the generated <file>.

[mv200580]

sure, @phanimahesh

trace_log.txt

I can see the published messages in trace log:
15:08:18.822 [info] Client(clientid@178.18.110.19:64866): SEND PUBLISH(Q0, R0, D0, Topic=oneM2M/req/557, PacketId=undefined, Payload=<<"message1">>)

but they are not processed by paho MqttMessageListener

[mv200580]

@phanimahesh

another weird thing
if I subscribe the client to the local topic wildcard oneM2M/req/# (instead of shared $queue/oneM2M/req/#), it begins to process messages in MqttMessageListener, while the trace is identical:

trace_log2.txt

[hezhijun]

+1

[ig0r]

guys, do you have any estimates on this issue?

[mruepp]

Hi, I suspect this problem concerns node-red mqtt node as well, there is also the paho client used and subscription is not working on local, queue and share

[emqplus]

@mruepp @mv200580 @ig0r I will close this issue now for lots of users of EMQ use shared subscription to consume sensor data. The tools like mqtt.FX will not show MQTT messages from shared subscription. For example, a '$queue/topic' is subscribed, but messages from 'topic' are published to the tool which will drop them silently.

[mv200580]

@emqplus I am not sure that clearly understand your last post.. So you don't plan to maintain the shared subscription feature for the java clients?
Or there is some bug in eclipse paho client that do not allow shared subscription to work properly?

[phanimahesh]

@emqplus A simple solution to ensure universal support would be to publish topics to $queue/topic instead of topic by rewriting the messages. Are there any potential downsides to doing this? It can possibly turned into a configurable option.

@mv200580 I'm not sure where the bug is, can't comment without doing some research. Shared subscriptions are not part of the spec, so implementations differ. Essentially java clients are rejecting any messages from topics they aren't subscribed to, even if they receive them. They asked for messages from $queue/topic but when they get messages from topic, they don't like it and silently ignore them.

I wonder how they handle messages from $client/clientid? EMQ subscribes every client to that by default, client doesn't have to request it. Do these clients drop messages sent on this topic?

[mv200580]

Thanks for reply, @phanimahesh !!
The problem is more clearly for me now.

I researched a bit java client behavior with messages from topic $client/clientid.

If client is not subscribed to that topic explicitly, it doesn't process messages published to that topic, despite the messages displayed in subscribed client trace log:

16:27:46.725 [info] Client(client_subs@161.8.91.106:65516): RECV CONNECT(Q0, R0, D0, ClientId=client_subs, ProtoName=MQTT, ProtoVsn=4, CleanSess=true, KeepAlive=60, Username=user, Password=***
***)
16:27:46.726 [info] Client(client_subs@161.8.91.106:65516): SEND CONNACK(Q0, R0, D0, AckFlags=0, RetainCode=0)
16:27:46.726 [info] Session(client_subs): Subscribe [{<<"$client/client_subs">>,[{qos,1}]}]
16:27:46.735 [info] Client(client_subs@161.8.91.106:65516): RECV SUBSCRIBE(Q1, R0, D0, PacketId=1, TopicTable=[{<<"req">>,1}])
16:27:46.735 [info] Session(client_subs): Subscribe [{<<"req">>,[{qos,1}]}]
16:27:46.736 [info] Client(client_subs@161.8.91.106:65516): SEND SUBACK(Q0, R0, D0, PacketId=1, QosTable=[1])
16:27:51.914 [info] Client(client_subs@161.8.91.106:65516): SEND PUBLISH(Q0, R0, D0, Topic=$client/client_subs, PacketId=undefined, Payload=<<"1212">>)
16:27:52.331 [info] Client(client_subs@161.8.91.106:65516): SEND PUBLISH(Q0, R0, D0, Topic=$client/client_subs, PacketId=undefined, Payload=<<"1212">>)
16:27:52.669 [info] Client(client_subs@161.8.91.106:65516): SEND PUBLISH(Q0, R0, D0, Topic=$client/client_subs, PacketId=undefined, Payload=<<"1212">>)

but if we subscribe the client explicitly to $client/clientid topic, then it begins to process messages:

16:26:26.795 [info] Client(client_subs@161.8.91.106:65473): RECV CONNECT(Q0, R0, D0, ClientId=client_subs, ProtoName=MQTT, ProtoVsn=4, CleanSess=true, KeepAlive=60, Username=user, Password=***
***)
16:26:26.797 [info] Client(client_subs@161.8.91.106:65473): SEND CONNACK(Q0, R0, D0, AckFlags=0, RetainCode=0)
16:26:26.797 [info] Session(client_subs): Subscribe [{<<"$client/client_subs">>,[{qos,1}]}]
16:26:26.806 [info] Client(client_subs@161.8.91.106:65473): RECV SUBSCRIBE(Q1, R0, D0, PacketId=1, TopicTable=[{<<"$client/client_subs">>,1}])
16:26:26.806 [info] Session(client_subs): Subscribe [{<<"$client/client_subs">>,[{qos,1}]}]
16:26:26.806 [warning] Session(client_subs): duplicated subscribe: $client/client_subs, qos = 1
16:26:26.807 [info] Client(client_subs@161.8.91.106:65473): SEND SUBACK(Q0, R0, D0, PacketId=1, QosTable=[1])
16:26:41.418 [info] Client(client_subs@161.8.91.106:65473): SEND PUBLISH(Q0, R0, D0, Topic=$client/client_subs, PacketId=undefined, Payload=<<"1212">>)
16:26:42.443 [info] Client(client_subs@161.8.91.106:65473): SEND PUBLISH(Q0, R0, D0, Topic=$client/client_subs, PacketId=undefined, Payload=<<"1212">>)
16:26:42.929 [info] Client(client_subs@161.8.91.106:65473): SEND PUBLISH(Q0, R0, D0, Topic=$client/client_subs, PacketId=undefined, Payload=<<"1212">>)

but the same doesn't work with $queue/topic and $share/topic, the client don't see the messages anyway

[mv200580]

Just want to find out now - is it possible for paho java client to switch off the topic name validation.. this can be the solution, I guess

[phanimahesh]

The client subscribes to $queue/topic but receives messages from topic. Not sure what'll happen if you subscribe to both.

…

On Thu 6 Apr, 2017 17:09 mv200580, ***@***.***> wrote: Just want to find out now - is it possible for paho java client to switch off the topic name validation.. this can be the solution, I guess — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#921 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnL8ERpyZ76-wq0XoSIqk8XU5jpdH66ks5rtM7lgaJpZM4MLMJV> .