[ 
https://issues.apache.org/jira/browse/NIFI-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-2774:
-----------------------------------
    Comment: was deleted

(was: Looking further into this the use of we can't really rely on session QoS 
attributes since they are meaningless across sessions. This means hat 
un-acknowledged message on the crashing NiFi is already lost upon the restart 
of NiFi since at that point the interaction with JMS will be done using new 
Session. The only true and reliable way of handling it is thru local 
transaction (as was suggested in the original comment). Basically create an 
instance of the TX manager as part of the ConsumetJMS processor and 
commit/rollback transaction after FF is disposed. )

> 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
>            Reporter: Christopher McDermott
>            Assignee: Oleg Zhurakousky
>            Priority: Critical
>             Fix For: 1.1.0, 0.8.0
>
>         Attachments: 2774.patch
>
>
> 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)

Reply via email to