[
https://issues.apache.org/jira/browse/NIFI-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407261#comment-15407261
]
ASF GitHub Bot commented on NIFI-2035:
--------------------------------------
Github user YolandaMDavis commented on the issue:
https://github.com/apache/nifi/pull/690
@markap14 retried tests again using a similar setup as before yet included
an input port on the standalone server in addition to the output port.
Performed a variety of tests attempting to create and update connections made
to and from the Remote Processor Group. I did see (after deleting ports and
waiting 30 seconds) that an appropriate error message was received based on the
null checks you made on your last commit. And when I attempted to delete and
create/update a connection quickly I saw the system eventually display a
warning bulletin that the connection was invalid.
I was unable to trigger any of the IllegalArgumentExceptions that were
added to verifyCreate in the StandardConnectionDAO, which made me wonder
whether or not recent changes prevented that from even occurring? Or whether
that it's a very small edge case being accounted for?
> Connection creation needs to verify that source and destination both exist
> during 1st phase of 2 phase commit
> -------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-2035
> URL: https://issues.apache.org/jira/browse/NIFI-2035
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> When a connection is created, we don't verify in the first step that both the
> source and destination exist. In the case of a Remote Process Group, where
> the ports change in the background, this can become problematic, we one node
> in the cluster may not have the same ports as another and the connection
> creation could end up failing on that node, resulting in the node getting
> kicked out of the cluster. We should also verify that the new destination
> exists when updating a connection if its destination changes, as this could
> happen there as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
