Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/529#discussion_r72186650
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-site-to-site/src/main/java/org/apache/nifi/remote/StandardRemoteGroupPort.java
---
@@ -366,6 +371,17 @@ private int receiveFlowFiles(final Transaction
transaction, final ProcessContext
return flowFilesReceived.size();
}
+ private String createTransitUri(final Transaction transaction, String
sourceFlowFileIdentifier) {
+ // Use actual uri as transitUri if this transport protocol has
meaningful uri.
+ switch (remoteGroup.getTransportProtocol()) {
--- End diff --
Hmm. Theoretically, I agree with that. However, there're couple of reasons
I ended up writing code like that:
1. Existing Socket site-to-site transit URI has `sourceFlowFileIdentifier`
in it, which can't be a part of the URI that the communicant knows. I think
this can be removed since a provenance event has `sourceSystemFlowFileId`. If
it's ok to change existing rule, then we can use communicant url as transit url
here.
2. There're two URLs in this context, one is Communicant (Peer) url,
another is CommunicationsSession's url. For RAW socket, both look the same as
"nifi://{hostname}:{port}". For HTTP,
Peer.url="http://{hostname}:{port}/nifi-api";,
CommunicationsSession.url="http://{hostname}:{port}/nifi-api/data-transfer/input-ports/{uuid}/transactions/{tx-id}/flow-files";.
I thought CommunicationsSession's url is more appropriate for transit url.
Having said that, I think those distinction shouldn't exist here in
StandardRemoteGroupPort. I will move those to more protocol specific classes.
Thanks @markap14 for your comment!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
