[
https://issues.apache.org/jira/browse/NIFI-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721845#comment-16721845
]
Yan Chen commented on NIFI-5896:
--------------------------------
[~markap14] Not seeing anything suspicious in the logs. Want to add more info
which might be relevant for the investigation: (1). batch-size 1 turned out not
working around the problem after all; we were lucky over last night but seeing
"Unacked" count increasing again right now. (2). we run 3-nodes NiFi cluster,
and the ConsumeAMQP processor is scheduled to execute on "Primary node only".
(3). I do notice that we had a change of Primary NiFi node in the cluster
today. This makes wonder whether the symptom has something to do with NiFi
switching primary node when the Consumer is configure to execute on primary
node only?
> ComsumeAMQP lose/unack messages under certain conditions
> --------------------------------------------------------
>
> Key: NIFI-5896
> URL: https://issues.apache.org/jira/browse/NIFI-5896
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.8.0
> Reporter: Yan Chen
> Priority: Major
>
> Symptoms: when batch-size is larger than 1 (tested with 10 and 100), the
> processor would *occasionally*:
> (1). when in auto-ack mode: lose messages, i.e., messages consumed from
> server but without producing flowfiles;
> (2). when auto-ack is disabled, messages could get stuck in "unacked" mode.
> We also found a work-around with batch-size 1 with auto-ack off; this
> work-around seems reliable enough.
> Based on above symptoms and the work-around, it appears to be a
> race-condition related issue. (for the same reason, I could not provide a
> test-case to reliably recreate the symptom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
