nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Zhurakousky (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart
Date Thu, 15 Sep 2016 12:41:20 GMT

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

Oleg Zhurakousky edited comment on NIFI-2774 at 9/15/16 12:40 PM:
------------------------------------------------------------------

I was about to suggest to change the type of this issue to "Improvement" since it never claimed
to allow multiple ack modes, hence not a bug, but. . .

I am actually wondering now if we should even expose AUTO_ACK or any ACK mode other then _Session.CLIENT_ACKNOWLEDGE_?
My concern is that it will go counter to the contract established by NiFi. 
First, the NiFi is not a general purpose framework to simplify interaction with JMS, so the
goal is not that.
Second, when integrating with external systems, NiFi essentially establishes a contract where
it attempts to the best of its ability to provide atomic consumption of data (from external
system to NiFi content repo, or nothing) between the external system and the processor that
integrates with such system, hence it should never expose any attribute that may break such
contract.

So unless overruled I am now treating it as a BUG and making an internal change to use _Session.CLIENT_ACKNOWLEDGE_
mode, yet not exposing anything new to the end user.


was (Author: ozhurakousky):
I was about to suggest to change the type of this issue to "Improvement" since it never claimed
to allow multiple ack modes, hence not a bug, but. . .

I am actually wondering now if we should even expose AUTO_ACK or an ACK mode other then _Session.CLIENT_ACKNOWLEDGE_?
My concern is that it will go counter to the contract established by NiFi. 
First, the NiFi is not a general purpose framework to simplify interaction with JMS, so the
goal is not that.
Second, when integrating with external systems, NiFi essentially establishes a contract where
it attempts to the best of its ability to provide atomic consumption of data (from external
system to NiFi content repo, or nothing) between the external system and the processor that
integrates with such system, hence it should never expose any attribute that may break such
contract.

So unless overruled I am now treating it as a BUG and making an internal change to use _Session.CLIENT_ACKNOWLEDGE_
mode, yet not exposing anything new to the end user.

> ConsumeJMS processor losses messages on NiFi restart
> ----------------------------------------------------
>
>                 Key: NIFI-2774
>                 URL: https://issues.apache.org/jira/browse/NIFI-2774
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 1.0.0, 0.7.0, 1.1.0, 0.8.0
>            Reporter: Christopher McDermott
>            Assignee: Oleg Zhurakousky
>            Priority: Critical
>             Fix For: 1.1.0, 0.8.0
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated GetJMSQueue processor
it does not provide a way to specify a different ACK mode (i.e. client-acknowledge.)  Using
auto-acknowledge, acknowledges message receipt from JMS *before* the messages are actually
added to the flow.  This leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in the processor
configuration like is allowed by the GetJMSQueue processor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message