Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Android MQTT service disconnection issue with QoS=1 and RabbitMQ server

Hi Cristiano,

thanks.  Yes, I realize that these functions do have implications for QoS and cleansession.  That's one of the reasons we haven't implemented it before.  Many client implementations seem to ignore the potential problems though, and users of them seem to be happy, and expect automatic reconnect and publish while disconnected.

I was thinking that ideally the interface could be totally refactored, so that a typical sequence of operations could be:

- create client
- connect (even this could be optional, but indicates that you want to be connected)
    - limit the options that can be used, no cleansession=true for instance
- subscribe, if desired
- publish, whether connected or not
- disconnect (again, could be optional)

connectionLost is never called.  Maybe another callback is created to just to indicate when the connection has been lost, but you don't have to implement the reconnect yourself.

Ian

On 07/10/2015 10:52, De Alti, Cristiano wrote:
Hi,
  We used this approach in the Eclipse Kura Project (automatic reconnect + publish while disconnected) [1].
Note that publishing while disconnected may have serious implications on the semantic of the the MQTT QoS, especially if you connect with "Clean Session" equal to false.

[1] https://github.com/eclipse/kura/tree/develop/kura/org.eclipse.kura.core/src/main/java/org/eclipse/kura/core

Ciao,
  Cristiano

On 07/10/2015 11:32, Ian Craggs wrote:
Hi All,

we are working (well, mainly James Sutton is) to make the Android service more stable.  Any feedback on what needs to be addressed will be helpful. 

We are also thinking that maybe a clean slate with the Android service might be a good option.  Keep the Java client base, but design a new Android layer above it (the old one would still exist of course).  What do you all think?

We're also wanting to add automatic reconnect and the ability to publish messages while disconnected.  As we want to add this in the base Java client, the Android service should be able to take advantage of that rather than duplicate the function.

Ian



On 10/05/2015 01:15 PM, Prashant Kedia wrote:
Agreed with Manuel. Paho Android Service is not stable, but I think it will take less efforts to tune Android service as compare to java client.

Actually I am myself using Java Client with android, but it's only because I am using it since before Android service was available and now it would be time consuming for me to switch to Android Service. Beside this I have already tuned Java Client good enough. 

On Mon, Oct 5, 2015 at 5:18 PM, Manuel Domínguez Dorado <manolodd@xxxxxxxxx> wrote:
Hi Milind.

Some other people here are recommending you to use Paho Android Service  for your purposes. Me too. However, be concious that the Paho Android Service (and MqttAndroidClient) is not as stable as the usual Paho Java.

Android client will take care of sending ping even when the device is in stand-by. But will not take care of reconnecting. So you need to implement your own logic.

Finally, I've been using Paho Android Service for near and I think that it is a product that need to be stabilised, improved and reviewed. There are lots of small things that don't work the same way than the corresponding Paho Java client, although they are supposed to work the same way. If you mix this with Android events like "screen orientation change" or similar, this could be very difficult to be tuned correctly. It's a bit anoying. So... yes, use Android Service Paho client but do not expect a smooth transition from the Paho Java client.

Regards.
 

2015-10-05 9:14 GMT+02:00 Milind Utsav <milind.utsavbk@xxxxxxxxx>:
I am trying to implement a push notification service for Android clients. The server is RabbitMQ with the MQTT adapter. The client on Android is of course, Paho Java client. The server side is Paho in Python sendin QoS 1 messages.

I couldn't get the connection to work reliably. Every now and then, the connection times out and the client is disconnected. In the RabbitMQ console, I can see that there are no active consumers listening to the topic. The Android client doesn't receive messages post that, until you restart the app, and hence the service. In a real world scenario, I can't expect customers to reopen the app everytime to get the notifications.

Right now, I am having a keepalive duration of 120s, which improved the performance of delivery from when the value was 60 s, but only slightly.

Are there any recommendations as to how I should tune my connections to make them more reliable?

--
Milind Utsav

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev



--
---
Manuel Domínguez Dorado
ingeniero ARROBA ManoloDominguez PUNTO com
http://www.ManoloDominguez.com

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev



--
Thanks and Regards,

Prashant Kedia
Co-Founder and Developer
Bizlers Technologies Pvt. Ltd.


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

-- 
Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto



_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

--
Cristiano De Alti
Principal Software Engineer

direct:    +39 0433 485468

EUROTECH
Imagine.Build.Succeed.
HEADQUARTERS
EUROTECH S.p.A. – Via Fratelli Solari, 3/a | 33020 Amaro UD | Italy | Tel. +39. 0433 485411  | Fax +39. 0433 485499 |
Cap. Soc. 8.878.946,00 € I.V. | P.IVA / C.F.: IT 01791330309 | REA Udine 196115
www.eurotech.com
____________________________________

Il presente messaggio ed ogni suo allegato sono da intendersi inviati esclusivamente agli effettivi destinatari e potrebbero essere soggetti a restrizioni legali. Se avete ricevuto questo messaggio per errore vi invitiamo a darne immediata notifica al mittente e cancellarlo dal vostro sistema. Qualsiasi altro uso di questo messaggio da parte vostra e' strettamente proibito.
 
This e-mail, and any file attached to it, is meant only for the intended recipient of the transmission and may be a communication privileged by law. If you have received it in error, please notify the sender immediately and delete the original from your system. Any other use of this e-mail by you is strictly forbidden.
____________________________________
 
Per favore, pensate all’ambiente prima di stampare questa e-mail. Please consider the environment before printing this e-mail.


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top