blob: 7d3684908bed8ef8e1f905ad10d0f363f40d25fb [file] [log] [blame]
<!DOCTYPE html>
<html lang="en">
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<head>
<meta charset="utf-8" />
<title>ConsumeMQTT</title>
<link rel="stylesheet" href="../../../../../css/component-usage.css" type="text/css" />
</head>
<body>
<p>The MQTT messages are always being sent to subscribers on a topic regardless of how frequently the processor is scheduled to run.
If the 'Run Schedule' is significantly behind the rate at which the messages are arriving to this processor, then a back up can occur
in the internal queue of this processor. Each time the processor is scheduled, the messages in the internal queue will be written to
FlowFiles. In case the internal queue is full, the MQTT client will try for up to 1 second to add the message into the internal queue.
If the internal queue is still full after this time, an exception saying that 'The subscriber queue is full' would be thrown, the
message would be dropped and the client would be disconnected. In case the QoS property is set to 0, the message would be lost. In
case the QoS property is set to 1 or 2, the message will be received after the client reconnects.</p>
</body>
</html>