You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Marton Szasz (Jira)" <ji...@apache.org> on 2021/07/30 07:41:00 UTC

[jira] [Resolved] (MINIFICPP-1610) Fix PublishKafka::notifyStop message interruption, reduce PublishKafkaOnScheduleTests runtime

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

Marton Szasz resolved MINIFICPP-1610.
-------------------------------------
    Resolution: Fixed

> Fix PublishKafka::notifyStop message interruption, reduce PublishKafkaOnScheduleTests runtime
> ---------------------------------------------------------------------------------------------
>
>                 Key: MINIFICPP-1610
>                 URL: https://issues.apache.org/jira/browse/MINIFICPP-1610
>             Project: Apache NiFi MiNiFi C++
>          Issue Type: Improvement
>            Reporter: Marton Szasz
>            Assignee: Marton Szasz
>            Priority: Major
>             Fix For: 0.11.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> With MINIFICPP-1351, I introduced a connection lock before the message lock to avoid a race condition on closing the connection. It went before the message lock, because when both are taken, connection lock has to come first to avoid a deadlock.
> This caused notifyStop to wait until the messages in flight timed out and onTrigger stopped before being able to take the connection lock, then the message lock, then interrupt the messages, thus defeating the interruption.
> This issue is about fixing the situation by first taking the message lock without the connection lock, interrupting the messages, then releasing the lock and taking the connection lock (after onTrigger terminated early, thanks to the interruptions) and terminating the connection.
>  
> Aside from that, I made an effort to reduce the runtime of PublishKafkaOnScheduleTests when no local kafka nodes are running. It tries to connect to one and waits for timeout, but the test doesn't need an actual running broker, this is just a side effect. Reduced timeouts, the runtime went from ~30sec to ~1.5sec.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)