[
https://issues.apache.org/jira/browse/NIFI-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270063#comment-17270063
]
Kay-Uwe Moosheimer commented on NIFI-8164:
------------------------------------------
Pierre, you are right. I missed that out.
> ConsumeMQTT validation bug
> --------------------------
>
> Key: NIFI-8164
> URL: https://issues.apache.org/jira/browse/NIFI-8164
> Project: Apache NiFi
> Issue Type: Improvement
> Affects Versions: 1.12.1
> Reporter: Kay-Uwe Moosheimer
> Priority: Major
>
> In ConsumeMQTT.java the following lines (196-200)
> final boolean clientIDSet = context.getProperty(PROP_CLIENTID).isSet();
> final boolean groupIDSet = context.getProperty(PROP_GROUPID).isSet();
> if (clientIDSet && groupIDSet) {
> results.add(new ValidationResult.Builder().subject("Client ID and Group
> ID").valid(false).explanation("if client ID is not unique, multiple nodes
> cannot join the consumer group").build());
> }
> are counterproductive.
> It is true that a client ID must be unique for multiple mqtt clients to join
> a consumer group.
> If you enter the client ID as ${hostname()}-client, then the client ID is
> unique (if you use this only once per node).
> But this is not possible with the validation.
> On the other hand it makes no sense if the client ID is random and you set
> the session state to "resume session". A random client ID can never resume a
> previous session.
> In general it is also not advisable but only an add-on for lazy typists if
> you don't use a unique client ID to auto generate a UUID. Because then only
> random client IDs appear on the broker, which cannot be assigned to a certain
> processor/node easily or not at all (monitoring nightmare).
> Therefore please delete these lines, because ConsumeMQTT is applicable in
> this way but not really in a proper way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
