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

ASF GitHub Bot commented on NIFI-2078:
--------------------------------------

Github user ijokarumawak commented on the issue:

    https://github.com/apache/nifi/pull/563
  
    @JPercivall @olegz Thanks for reviewing this! I've rebased the branch, and 
addressed the feedback. However, while I was testing this again, I noticed that 
if it's running on a clustered NiFi environment, every node gets and clears 
offsets from Kafka. While it's working, I think these method should be executed 
on only the primary node, or if it's a standalone instance since offsets 
information is a global state among consumers.
    
    With `@OnPrimaryNodeStateChange` annotation, it's possible to know if it's 
a cluster and a primary node. But it's only called if a node get elected as a 
primary, or a node was primary but revoked. Since other node is not notified, I 
couldn't distinguish standalone or primary from a processor..
    So, I left it as it is for now. Do you know If there's a way to know if 
NiFi is clustered from a processor?


> State management for processors whose states are managed externally
> -------------------------------------------------------------------
>
>                 Key: NIFI-2078
>                 URL: https://issues.apache.org/jira/browse/NIFI-2078
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core Framework
>            Reporter: Koji Kawamura
>            Assignee: Koji Kawamura
>             Fix For: 1.0.0
>
>
> Inherently by the nature of a given processor it may involve state managed by 
> itself (using nifi state management), or can be managed by some external 
> service it interacts with (kafka's offset), and theoretically some might have 
> both going on. With the new state management, we're giving users a way to 
> reset state managed by nifi for a given processor. But it doesnt apply to 
> those processors who have external state.
> we should consider offering a way to reset state that allows a processor to 
> call out to whatever external store it impacts



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

Reply via email to