Uploaded image for project: 'ActiveMQ'
  1. ActiveMQ
  2. AMQ-5040

Issue with Eclipse Paho mobile client and reconnecting due to failure.

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not A Problem
    • Affects Version/s: 5.7.0
    • Fix Version/s: 5.9.0
    • Component/s: MQTT
    • Labels:
      None
    • Environment:

      Ubuntu 12.04

      Description

      A similar issue as the original one still exists with the 5.9.0 version. When a connection breaks to the broker, for example a WiFi connection breaks, and the phone reconnects via mobile network, the MqttService retries connecting to the broker. The client responds with "Broker unavailable (3)", and in the broker console the same "already connected" message appears as with the original post.

      The same issue is when the WiFi is turned off, then on. Every reconnect actually results in the same error.

      The code is more or less identical.

      -------------------------------------
      I built client that is connecting to Apache MQ set for mqtt.

      Now on first try client establishes the connection with client id = test1, sends message and closes connection

      if(!client.isConnected())

      { client.connect(conOpt); }

      MqttTopic topic = client.getTopic(topicName);

      MqttMessage message = new MqttMessage(payload);
      message.setQos(qos);
      MqttDeliveryToken token = topic.publish(message);
      token.waitForCompletion();
      client.disconnect();

      Then when again I run client it fails on connect ... I can see log in apache mq log:

      WARN | Transport Connection to: tcp://127.0.0.1:57354 failed: java.io.IOExcepti
      on: Broker: localhost - Client: test1 already connected from tcp://127.0.0.1:57
      330

      in connection options I have set only setCleanSession(true). Paho client I have downloaded from site as stable version.

      I have first tried to raise an issue with the Eclipse Paho project (https://bugs.eclipse.org/bugs/show_bug.cgi?id=408105) and after investigation their team came to conclusion that this is not on clinet side

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                salex89 Aleksandar Stojadinovic
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: