[ 
https://issues.apache.org/jira/browse/CAMEL-11628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197563#comment-16197563
 ] 

Brad Powell edited comment on CAMEL-11628 at 10/9/17 7:23 PM:
--------------------------------------------------------------

I, too, could really use a fix for this bug.

By the way, camel-paho isn't always an option, due to things like the lack of 
ability to dynamically specify the topic for a producer endpoint. With the mqtt 
component this is possible via the CamelMQTTPublishTopic header.

As for reproducing this bug:

1. Use the route listed below.
2. Start an MQTT broker.
    2.a. I've tried Mosquitto 1.4.14 under RHEL 7.2 as well as Mosquitto 1.4.11 
under Windows 7.
3. Start the route.
4. After a few seconds, kill the MQTT broker.
5. Wait roughly 30 seconds, at which point you'll start gettting "Failed 
delivery..." errors (and "camel:route-list" will start showing failed 
exchanges).
6. Start the MQTT broker back up.
7. Bug shows up:

Camel log starts outputting tons of the following messages:
    INFO  | spatch-DEFAULT-1 | MQTTEndpoint                     | 153 - 
org.apache.camel.camel-mqtt - 2.17.0 | MQTT Connection connected to 
tcp://localhost:1883

Mosquitto repeatedly outputs the following set of message:
    New client connected from 127.0.0.1 as tmr2mqttClient (c1, k30).
    Sending CONNACK to tmr2mqttClient (0, 0)
    New connection from 127.0.0.1 on port 1883.
    Client tmr2mqttClient already connected, closing old connection.
    Client tmr2mqttClient disconnected.

Mosquitto's behavior is indicative of an MQTT client process (Camel in this 
case) using the same clientID to establish a new connection, when a connection 
using that same clientID already exists. Per MQTT spec, Mosquitto will 
disconnect the current connection with that clientID, and then accept the new 
connection.

+Route to use+
{{  <camelContext id="blueprint-ctx-for-mqtt" 
xmlns="http://camel.apache.org/schema/blueprint";>
    <route id="timerToMqtt">
      <from uri="timer:toMqtt?period=1000"/>
      <setHeader headerName="CamelMQTTPublishTopic">
          <simple>camelTopic-${date:now:ss}</simple>
      </setHeader>
      <setBody>
          <simple>${date:now:yyyyMMdd-HH:mm:ss.SSS}</simple>
      </setBody>
      <log message="The message contains ${body}"/>
      <to 
uri="mqtt://tmr2mqttPublisher?host=tcp://localhost:1883&amp;clientId=tmr2mqttClient&amp;cleanSession=true&amp;qualityOfService=AtMostOnce&amp;connectWaitInSeconds=5&amp;reconnectAttemptsMax=5&amp;reconnectDelay=500&amp;reconnectDelayMax=5000"/>
    </route>
  </camelContext>
}}


was (Author: bapowell):
I, too, could really use a fix for this bug.

By the way, camel-paho isn't always an option, due to things like the lack of 
ability to dynamically specify the topic for a producer endpoint. With the mqtt 
component this is possible via the CamelMQTTPublishTopic header.

As for reproducing this bug:

1. Use the route listed below.
2. Start an MQTT broker.
    2.a. I've tried Mosquitto 1.4.14 under RHEL 7.2 as well as Mosquitto 1.4.11 
under Windows 7.
3. Start the route.
4. After a few seconds, kill the MQTT broker.
5. Wait roughly 30 seconds, at which point you'll start gettting "Failed 
delivery..." errors (and "camel:route-list" will start showing failed 
exchanges).
6. Start the MQTT broker back up.
7. Bug shows up:

Camel log starts outputting tons of the following messages:
    INFO  | spatch-DEFAULT-1 | MQTTEndpoint                     | 153 - 
org.apache.camel.camel-mqtt - 2.17.0 | MQTT Connection connected to 
tcp://localhost:1883

Mosquitto repeatedly outputs the following set of message:
    New client connected from 127.0.0.1 as tmr2mqttClient (c1, k30).
    Sending CONNACK to tmr2mqttClient (0, 0)
    New connection from 127.0.0.1 on port 1883.
    Client tmr2mqttClient already connected, closing old connection.
    Client tmr2mqttClient disconnected.

Mosquitto's behavior is indicative of an MQTT client process (Camel in this 
case) using the same clientID to establish a new connection, when a connection 
using that same clientID already exists. Per MQTT spec, Mosquitto will 
disconnect the current connection with that clientID, and then accept the new 
connection.

+Route to use+
  <camelContext id="blueprint-ctx-for-mqtt" 
xmlns="http://camel.apache.org/schema/blueprint";>
    <route id="timerToMqtt">
      <from uri="timer:toMqtt?period=1000"/>
      <setHeader headerName="CamelMQTTPublishTopic">
          <simple>camelTopic-${date:now:ss}</simple>
      </setHeader>
      <setBody>
          <simple>${date:now:yyyyMMdd-HH:mm:ss.SSS}</simple>
      </setBody>
      <log message="The message contains ${body}"/>
      <to 
uri="mqtt://tmr2mqttPublisher?host=tcp://localhost:1883&amp;clientId=tmr2mqttClient&amp;cleanSession=true&amp;qualityOfService=AtMostOnce&amp;connectWaitInSeconds=5&amp;reconnectAttemptsMax=5&amp;reconnectDelay=500&amp;reconnectDelayMax=5000"/>
    </route>
  </camelContext>


> MQTT Connection loop
> --------------------
>
>                 Key: CAMEL-11628
>                 URL: https://issues.apache.org/jira/browse/CAMEL-11628
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-mqtt
>    Affects Versions: 2.17.0
>            Reporter: Fabrizio Spataro
>
> Hello everyone, i found an particular bug situation
> I have same mqtt producer with high volume traffic. When my application losts 
> tcp connection to mqtt server i have follow connection loop error. This bug 
> is sometime verified because it depend by multiple factors (load machine, 
> load mqtt server, payload, etc)
> I am reading source code and i suppose that the bug is introduced by volatile 
> variable connected (it isn't thread-safe)
> To resolve this bug you must refactoring all MQTTEndpoint connection code.
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883
> [        hawtdispatch-DEFAULT-3] MQTTEndpoint                   INFO  MQTT 
> Connection connected to tcp://mqtt:1883



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to