You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Ádám Markovics (Jira)" <ji...@apache.org> on 2022/11/17 11:03:00 UTC

[jira] [Commented] (MINIFICPP-1985) Use asio related tests on random ports

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

Ádám Markovics commented on MINIFICPP-1985:
-------------------------------------------

This random port that the OS assigns must be an unused one, right? I think it's even more important than being random, that might affect naming functions or documentation.

> Use asio related tests on random ports
> --------------------------------------
>
>                 Key: MINIFICPP-1985
>                 URL: https://issues.apache.org/jira/browse/MINIFICPP-1985
>             Project: Apache NiFi MiNiFi C++
>          Issue Type: Improvement
>            Reporter: Martin Zink
>            Assignee: Martin Zink
>            Priority: Minor
>
> The tests in question are PutTCPTests, PutUDPTests, ListenTCPTests, ListenUDPTests.
> We shouldn't use hard coded ports to run the tests on.
> I've tried creating a test utility that creates a socket on port 0. (so the OS assigns a random port to it), then close the socket and return the port to bind to.
> Unfortunately this could leave the port on TIME_WAIT (which could be workaround by setting reuse_address (which we may very well want to use besides this, so restarting the processor on the same port can work without hiccups), but due to race conditions sometimes the port is not even in the TIME_WAIT state when the processor wants to bind to it.
>  
> The proper solution would be to directly set the processor (or utility) to port 0. And get the listening port out after the socket/acceptor is already up and running, this would require a larger refactor (both tests and prod code as well), it would make sense to do this during the MINIFICPP-1979 refactor.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)