You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Mark Payne (JIRA)" <ji...@apache.org> on 2018/12/28 15:25:00 UTC

[jira] [Commented] (NIFI-5919) Occasionally FlowFiles appear to get "stuck" in a Load-Balanced Connection

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

Mark Payne commented on NIFI-5919:
----------------------------------

While I have spent a significant amount of time testing and trying to replicate this, my efforts have always focused on a Connection between two Processors. When I created a Load-Balanced Connection between two Ports (i.e., between two different Process Groups), I was able to observe/replicate the issue. I saw the following in my logs when this occurred:

2018-12-27 23:51:57,491 ERROR [Timer-Driven Process Thread-46] org.apache.nifi.connectable.LocalPort LocalPort[id=f214634f-0167-1000-ffff-ffffeb95d88c] LocalPort[id=f214634f-0167-1000-ffff-ffffeb95d88c] failed to process session due to java.lang.RuntimeException: java.lang.IllegalArgumentException; Processor Administratively Yielded for 1 sec: java.lang.RuntimeException: java.lang.IllegalArgumentException
java.lang.RuntimeException: java.lang.IllegalArgumentException
        at org.apache.nifi.controller.AbstractPort.onTrigger(AbstractPort.java:257)
        at org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:205)
        at org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: null
        at org.apache.nifi.controller.queue.QueueSize.<init>(QueueSize.java:31)
        at org.apache.nifi.controller.queue.QueueSize.add(QueueSize.java:67)
        at org.apache.nifi.controller.queue.clustered.SocketLoadBalancedFlowFileQueue.adjustSize(SocketLoadBalancedFlowFileQueue.java:587)
        at org.apache.nifi.controller.queue.clustered.SocketLoadBalancedFlowFileQueue.acknowledge(SocketLoadBalancedFlowFileQueue.java:901)
        at org.apache.nifi.controller.repository.StandardProcessSession.acknowledgeRecords(StandardProcessSession.java:1184)
        at org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:469)
        at org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:342)
        at org.apache.nifi.controller.AbstractPort.onTrigger(AbstractPort.java:251)
        ... 9 common frames omitted


> Occasionally FlowFiles appear to get "stuck" in a Load-Balanced Connection
> --------------------------------------------------------------------------
>
>                 Key: NIFI-5919
>                 URL: https://issues.apache.org/jira/browse/NIFI-5919
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>            Reporter: Mark Payne
>            Assignee: Mark Payne
>            Priority: Major
>
> When a Connection is configured to Load Balance across the cluster, we have seen reports on the mailing list of FlowFiles getting "stuck". The connection shows that the data is being actively load balanced, but the FlowFiles never move. Listing or emptying the queue indicate that there are no FlowFiles. Upon restart, the FlowFile does not exist and the queue is cleared.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)