[
https://issues.apache.org/jira/browse/NIFI-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721415#comment-16721415
]
Joseph Witt commented on NIFI-5896:
-----------------------------------
auto-ack on would effectively mean 'at-most-once' configuration.
auto-ack off with explicit ack would effectively mean 'at least once'. Can you
describe more how in auto-ack off conditions data was getting stuck (captured,
but not ack'd)?
> 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 messaged, 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)
