Server does't push Qos 1 messages to client after client reconnect

Bug #890724 reported by David Huang
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mosquitto
Fix Released
Undecided
Unassigned

Bug Description

I'm using sever version 0.13 and wmqtt.jar library. Below is the re-produce steps:
1) client connect to server and subscribe one topic using clean_state=false and Qos=1
2) Make the client lost the connection until the server side disconnecting by timeout.
3) publish some messages to the topic in the step 1).
4) Re-connect the client to the server with the same subscribe in step 1)
5) Client should receive the messages in the step 3) immediately after the connection. In fact server will not send the missed messages to the re-connected client except publishing a new message on this topic.

David Huang (bolixie)
description: updated
Revision history for this message
Roger Light (roger.light) wrote :

I don't see this problem myself. Could you check a few things?

Firstly, setting clean_session=false will only work if you are using the same client id when you reconnect. I'm not familiar with wmqtt.jar but if it doesn't require you to specify your own client id it may be generating a random (different) one when you reconnect.

The other thing to check is that the messages being published are also set QoS=1. If they have QoS=0 they will still be discarded even though your subscription has QoS=1.

Revision history for this message
David Huang (bolixie) wrote :

Hi Roger,

Yes i did use the same client id and publish message using Qos=1.

The point of this bug is server will not send missed messages to re-connected subscriptions until new publish messages to that topic. To re-produce the problem you have to wait the server disconnecting the connection by timeout. The log is: client some_id
 has exeeded timeout, disconnectiong.

I also tested the same steps using Really Small Message Broker 1.2. Re-connected clients can receive missed messages immediately after they re-connected to Really Small Message Broker.

Thanks
David

Revision history for this message
Roger Light (roger.light) wrote :

Hi David,

Ah, right. I missed the important point in your first message. It was much clearer the second time around. I can confirm the behaviour and agree it is a bug.

Cheers,

Roger

Changed in mosquitto:
milestone: none → 0.14
status: New → Confirmed
Revision history for this message
David Huang (bolixie) wrote : Re: [Bug 890724] Re: Server does't push Qos 1 messages to client after client reconnect

Hi Roger,

I'd like to try to fix it if possible. Could you please give me some simple
instructions on how to fix this bug? For example which source code file is
mainly related to this problem?

Thanks
David

2011/11/16 Roger Light <email address hidden>

> Hi David,
>
> Ah, right. I missed the important point in your first message. It was
> much clearer the second time around. I can confirm the behaviour and
> agree it is a bug.
>
> Cheers,
>
> Roger
>
> ** Changed in: mosquitto
> Status: New => Confirmed
>
> ** Changed in: mosquitto
> Milestone: None => 0.14
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/890724
>
> Title:
> Server does't push Qos 1 messages to client after client reconnect
>
> Status in mosquitto: an mqtt message broker:
> Confirmed
>
> Bug description:
> I'm using sever version 0.13 and wmqtt.jar library. Below is the
> re-produce steps:
> 1) client connect to server and subscribe one topic using
> clean_state=false and Qos=1
> 2) Make the client lost the connection until the server side
> disconnecting by timeout.
> 3) publish some messages to the topic in the step 1).
> 4) Re-connect the client to the server with the same subscribe in step 1)
> 5) Client should receive the messages in the step 3) immediately after
> the connection. In fact server will not send the missed messages to the
> re-connected client except publishing a new message on this topic.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mosquitto/+bug/890724/+subscriptions
>

Revision history for this message
Roger Light (roger.light) wrote :

Thanks for the offer, but I think it's already fixed. If you're happy compiling the code yourself, you can give the fix a try at this link: https://bitbucket.org/oojah/mosquitto/src/885e23ff76c4 There is a "get source" link on the right hand side of the page.

If you could confirm that it's fixed for you that'd be very helpful.

Changed in mosquitto:
status: Confirmed → Fix Committed
Revision history for this message
David Huang (bolixie) wrote :

Hi Roger,

I tested the last version=>0.13.9. The bug has been fixed. :)

Thanks a lot!
David

2011/11/16 Roger Light <email address hidden>

> Thanks for the offer, but I think it's already fixed. If you're happy
> compiling the code yourself, you can give the fix a try at this link:
> https://bitbucket.org/oojah/mosquitto/src/885e23ff76c4 There is a "get
> source" link on the right hand side of the page.
>
> If you could confirm that it's fixed for you that'd be very helpful.
>
> ** Changed in: mosquitto
> Status: Confirmed => Fix Committed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/890724
>
> Title:
> Server does't push Qos 1 messages to client after client reconnect
>
> Status in mosquitto: an mqtt message broker:
> Fix Committed
>
> Bug description:
> I'm using sever version 0.13 and wmqtt.jar library. Below is the
> re-produce steps:
> 1) client connect to server and subscribe one topic using
> clean_state=false and Qos=1
> 2) Make the client lost the connection until the server side
> disconnecting by timeout.
> 3) publish some messages to the topic in the step 1).
> 4) Re-connect the client to the server with the same subscribe in step 1)
> 5) Client should receive the messages in the step 3) immediately after
> the connection. In fact server will not send the missed messages to the
> re-connected client except publishing a new message on this topic.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mosquitto/+bug/890724/+subscriptions
>

Changed in mosquitto:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.