You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "lordgamez (via GitHub)" <gi...@apache.org> on 2026/02/05 10:06:44 UTC
[PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
lordgamez opened a new pull request, #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094
https://issues.apache.org/jira/browse/MINIFICPP-2709
------------
Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [ ] Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [ ] Has your PR been rebased against the latest commit within the target branch (typically main)?
- [ ] Is your initial contribution a single, squashed commit?
### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which it is rendered?
### Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "lordgamez (via GitHub)" <gi...@apache.org>.
lordgamez commented on code in PR #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094#discussion_r2799170800
##########
core-framework/src/http/HTTPStream.cpp:
##########
@@ -75,14 +73,12 @@ size_t HttpStream::write(const uint8_t* value, size_t size) {
size_t HttpStream::read(std::span<std::byte> buf) {
if (buf.empty()) { return 0; }
if (!IsNullOrEmpty(buf)) {
- if (!started_) {
- std::lock_guard<std::mutex> lock(mutex_);
- if (!started_) {
- auto read_callback = std::make_unique<HTTPReadByteOutputCallback>(66560, true);
- http_client_future_ = std::async(std::launch::async, submit_read_client, http_client_, read_callback.get());
- http_client_->setReadCallback(std::move(read_callback));
- started_ = true;
- }
+ std::lock_guard<std::mutex> lock(mutex_);
+ if (!read_started_) {
+ auto read_callback = std::make_unique<HTTPReadByteOutputCallback>(66560, true);
+ http_client_read_future_ = std::async(std::launch::async, submit_read_client, http_client_, read_callback.get());
+ http_client_->setReadCallback(std::move(read_callback));
+ read_started_ = true;
}
return gsl::not_null(getByteOutputReadCallback())->readFully(reinterpret_cast<char*>(buf.data()), buf.size());
Review Comment:
Calling the callback read outside the lock would make it possible to replace the callback from another thread while being read, so it should remain under the mutex.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094#discussion_r2798802419
##########
core-framework/src/http/HTTPStream.cpp:
##########
@@ -75,14 +73,12 @@ size_t HttpStream::write(const uint8_t* value, size_t size) {
size_t HttpStream::read(std::span<std::byte> buf) {
if (buf.empty()) { return 0; }
if (!IsNullOrEmpty(buf)) {
- if (!started_) {
- std::lock_guard<std::mutex> lock(mutex_);
- if (!started_) {
- auto read_callback = std::make_unique<HTTPReadByteOutputCallback>(66560, true);
- http_client_future_ = std::async(std::launch::async, submit_read_client, http_client_, read_callback.get());
- http_client_->setReadCallback(std::move(read_callback));
- started_ = true;
- }
+ std::lock_guard<std::mutex> lock(mutex_);
+ if (!read_started_) {
+ auto read_callback = std::make_unique<HTTPReadByteOutputCallback>(66560, true);
+ http_client_read_future_ = std::async(std::launch::async, submit_read_client, http_client_, read_callback.get());
+ http_client_->setReadCallback(std::move(read_callback));
+ read_started_ = true;
}
return gsl::not_null(getByteOutputReadCallback())->readFully(reinterpret_cast<char*>(buf.data()), buf.size());
Review Comment:
HttpStream::read() holds mutex_ while calling ByteOutputCallback::readFully(), which can block waiting for data/close. This prevents forceClose() (and the destructor) from acquiring the same mutex to close the callback and can deadlock shutdown/cleanup. Only hold mutex_ for one-time initialization of the read callback/future, then release it before the potentially-blocking readFully call (or use call_once/atomic state to guard initialization).
```suggestion
std::shared_ptr<ByteOutputCallback> read_callback;
{
std::lock_guard<std::mutex> lock(mutex_);
if (!read_started_) {
auto new_read_callback = std::make_unique<HTTPReadByteOutputCallback>(66560, true);
http_client_read_future_ = std::async(std::launch::async, submit_read_client, http_client_, new_read_callback.get());
http_client_->setReadCallback(std::move(new_read_callback));
read_started_ = true;
}
read_callback = getByteOutputReadCallback();
}
return gsl::not_null(read_callback)->readFully(reinterpret_cast<char*>(buf.data()), buf.size());
```
##########
core-framework/src/http/HTTPStream.cpp:
##########
@@ -40,30 +40,28 @@ void HttpStream::close() {
}
void HttpStream::seek(size_t /*offset*/) {
- // seek is an unnecessary part of this implementation
throw std::logic_error{"HttpStream::seek is unimplemented"};
}
size_t HttpStream::tell() const {
- // tell is an unnecessary part of this implementation
throw std::logic_error{"HttpStream::tell is unimplemented"};
}
-// data stream overrides
+[[nodiscard]] size_t HttpStream::size() const {
+ throw std::logic_error{"HttpStream::size is unimplemented"};
+}
size_t HttpStream::write(const uint8_t* value, size_t size) {
if (size == 0) return 0;
if (IsNullOrEmpty(value)) {
return io::STREAM_ERROR;
}
- if (!started_) {
- std::lock_guard<std::mutex> lock(mutex_);
- if (!started_) {
- auto callback = std::make_unique<HttpStreamingCallback>();
- http_client_->setUploadCallback(std::move(callback));
- http_client_future_ = std::async(std::launch::async, submit_client, http_client_);
- started_ = true;
- }
+ std::lock_guard<std::mutex> lock(mutex_);
+ if (!write_started_) {
+ auto callback = std::make_unique<HttpStreamingCallback>();
+ http_client_->setUploadCallback(std::move(callback));
+ http_client_write_future_ = std::async(std::launch::async, submit_client, http_client_);
+ write_started_ = true;
}
if (auto http_callback = dynamic_cast<HttpStreamingCallback*>(http_client_->getUploadCallback()))
http_callback->process(value, size);
Review Comment:
HttpStream::write() holds mutex_ while invoking HttpStreamingCallback::process(). Keeping the stream mutex held during callback processing unnecessarily serializes writers and can block forceClose() longer than needed. Consider limiting the mutex scope to just initializing the upload callback/future and releasing it before calling into the callback.
##########
libminifi/src/sitetosite/HttpSiteToSiteClient.cpp:
##########
@@ -388,4 +385,33 @@ void HttpSiteToSiteClient::setSiteToSiteHeaders(minifi::http::HTTPClient& client
}
}
+std::pair<uint64_t, uint64_t> HttpSiteToSiteClient::readFlowFiles(const std::shared_ptr<Transaction>& transaction, core::ProcessSession& session) {
+ auto http_stream = dynamic_cast<http::HttpStream*>(peer_->getStream());
+ if (!http_stream) {
+ throw Exception(SITE2SITE_EXCEPTION, "Reading flow files failed: stream cannot be cast to HTTP stream");
+ }
+
+ try {
+ return SiteToSiteClient::readFlowFiles(transaction, session);
+ } catch (const Exception&) {
+ auto response_code = http_stream->getClientRef()->getResponseCode();
+
+ // 200 tells us that there is no content to read, so we should not treat it as an error.
+ // The read fails in this case because the stream does not contain a valid response body with the expected format.
+ // Unfortunately there is no way to get the response code before trying to read, so we have to let it fail and check the response code afterwards.
+ if (response_code == 200) {
+ logger_->log_debug("Response code 200, no content to read");
+ transaction->setDataAvailable(false);
+ transaction->setState(TransactionState::TRANSACTION_CANCELED);
+ current_code_ = ResponseCode::CANCEL_TRANSACTION;
+ return {0, 0};
+ }
+ throw;
+ }
+
+ if (auto response_code = http_stream->getClientRef()->getResponseCode(); response_code >= 400) {
+ throw Exception(SITE2SITE_EXCEPTION, fmt::format("HTTP error code received while reading flow files: {}", response_code));
+ }
+}
Review Comment:
This response-code check is unreachable because both the try block and the catch block either return or rethrow. As written, it’s dead code and can also trigger “control may reach end of non-void function”/unreachable-code warnings depending on compiler settings. If you intended to validate HTTP status after a successful read, store the base readFlowFiles() result, then check the response code, then return the stored result; otherwise remove this block.
##########
libminifi/src/sitetosite/HttpSiteToSiteClient.cpp:
##########
@@ -388,4 +385,33 @@ void HttpSiteToSiteClient::setSiteToSiteHeaders(minifi::http::HTTPClient& client
}
}
+std::pair<uint64_t, uint64_t> HttpSiteToSiteClient::readFlowFiles(const std::shared_ptr<Transaction>& transaction, core::ProcessSession& session) {
+ auto http_stream = dynamic_cast<http::HttpStream*>(peer_->getStream());
+ if (!http_stream) {
+ throw Exception(SITE2SITE_EXCEPTION, "Reading flow files failed: stream cannot be cast to HTTP stream");
+ }
+
+ try {
+ return SiteToSiteClient::readFlowFiles(transaction, session);
+ } catch (const Exception&) {
+ auto response_code = http_stream->getClientRef()->getResponseCode();
+
+ // 200 tells us that there is no content to read, so we should not treat it as an error.
+ // The read fails in this case because the stream does not contain a valid response body with the expected format.
+ // Unfortunately there is no way to get the response code before trying to read, so we have to let it fail and check the response code afterwards.
+ if (response_code == 200) {
+ logger_->log_debug("Response code 200, no content to read");
+ transaction->setDataAvailable(false);
+ transaction->setState(TransactionState::TRANSACTION_CANCELED);
+ current_code_ = ResponseCode::CANCEL_TRANSACTION;
+ return {0, 0};
+ }
Review Comment:
The new 200-response special-case is behaviorally significant (treating an exception from parsing the body as “no content”). There are existing HTTPSiteToSite integration tests, but none appear to cover the “GET /flow-files returns 200 with empty/invalid Site-to-Site body” scenario. Please add an integration/unit test that exercises this path to prevent regressions.
##########
core-framework/include/http/HTTPStream.h:
##########
@@ -114,19 +102,16 @@ class HttpStream : public io::BaseStreamImpl {
}
inline bool isFinished(int seconds = 0) {
- return http_client_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
+ return http_client_read_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
&& getByteOutputReadCallback()
&& getByteOutputReadCallback()->getSize() == 0
&& getByteOutputReadCallback()->waitingOps();
}
- /**
- * Waits for more data to become available.
- */
bool waitForDataAvailable() {
do {
logger_->log_trace("Waiting for more data");
- } while (http_client_future_.wait_for(std::chrono::seconds(0)) != std::future_status::ready
+ } while (http_client_read_future_.wait_for(std::chrono::seconds(0)) != std::future_status::ready
&& getByteOutputReadCallback()
&& getByteOutputReadCallback()->getSize() == 0);
Review Comment:
HttpStream::waitForDataAvailable() also calls wait_for() on http_client_read_future_ without checking valid(), which can throw if no read() has been started yet. Add a valid()/read_started_ guard and define what should happen before the read is initiated (likely return false).
##########
core-framework/include/http/HTTPStream.h:
##########
@@ -114,19 +102,16 @@ class HttpStream : public io::BaseStreamImpl {
}
inline bool isFinished(int seconds = 0) {
- return http_client_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
+ return http_client_read_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
&& getByteOutputReadCallback()
&& getByteOutputReadCallback()->getSize() == 0
&& getByteOutputReadCallback()->waitingOps();
}
Review Comment:
HttpStream::isFinished() calls wait_for() on http_client_read_future_ without checking valid(). If isFinished() is called before any read() starts, std::future::wait_for will throw std::future_error. Guard with http_client_read_future_.valid() (and likely return false when not started).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "fgerlits (via GitHub)" <gi...@apache.org>.
fgerlits commented on code in PR #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094#discussion_r2799384820
##########
libminifi/include/sitetosite/SiteToSiteClient.h:
##########
@@ -171,6 +172,9 @@ class SiteToSiteClient {
std::atomic<std::chrono::milliseconds> batch_duration_{0s};
std::atomic<std::chrono::milliseconds> timeout_{0s};
+ protected:
Review Comment:
this `protected:` is not needed, we are already in the protected block (same in `HttpSiteToSiteClient.h`)
but no objection if you want to keep it for clarity
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "lordgamez (via GitHub)" <gi...@apache.org>.
lordgamez commented on code in PR #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094#discussion_r2799624861
##########
libminifi/include/sitetosite/SiteToSiteClient.h:
##########
@@ -171,6 +172,9 @@ class SiteToSiteClient {
std::atomic<std::chrono::milliseconds> batch_duration_{0s};
std::atomic<std::chrono::milliseconds> timeout_{0s};
+ protected:
Review Comment:
It was a mistake, updated in https://github.com/apache/nifi-minifi-cpp/pull/2094/commits/e6e4e042ff774eb4cb8921c0f12e090622e92a64
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "lordgamez (via GitHub)" <gi...@apache.org>.
lordgamez commented on code in PR #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094#discussion_r2799187364
##########
core-framework/src/http/HTTPStream.cpp:
##########
@@ -40,30 +40,28 @@ void HttpStream::close() {
}
void HttpStream::seek(size_t /*offset*/) {
- // seek is an unnecessary part of this implementation
throw std::logic_error{"HttpStream::seek is unimplemented"};
}
size_t HttpStream::tell() const {
- // tell is an unnecessary part of this implementation
throw std::logic_error{"HttpStream::tell is unimplemented"};
}
-// data stream overrides
+[[nodiscard]] size_t HttpStream::size() const {
+ throw std::logic_error{"HttpStream::size is unimplemented"};
+}
size_t HttpStream::write(const uint8_t* value, size_t size) {
if (size == 0) return 0;
if (IsNullOrEmpty(value)) {
return io::STREAM_ERROR;
}
- if (!started_) {
- std::lock_guard<std::mutex> lock(mutex_);
- if (!started_) {
- auto callback = std::make_unique<HttpStreamingCallback>();
- http_client_->setUploadCallback(std::move(callback));
- http_client_future_ = std::async(std::launch::async, submit_client, http_client_);
- started_ = true;
- }
+ std::lock_guard<std::mutex> lock(mutex_);
+ if (!write_started_) {
+ auto callback = std::make_unique<HttpStreamingCallback>();
+ http_client_->setUploadCallback(std::move(callback));
+ http_client_write_future_ = std::async(std::launch::async, submit_client, http_client_);
+ write_started_ = true;
}
if (auto http_callback = dynamic_cast<HttpStreamingCallback*>(http_client_->getUploadCallback()))
http_callback->process(value, size);
Review Comment:
Calling the callback process outside the lock would make it possible to replace the callback from another thread while being read, so it should remain under the mutex.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "lordgamez (via GitHub)" <gi...@apache.org>.
lordgamez commented on code in PR #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094#discussion_r2799238436
##########
core-framework/include/http/HTTPStream.h:
##########
@@ -114,19 +102,16 @@ class HttpStream : public io::BaseStreamImpl {
}
inline bool isFinished(int seconds = 0) {
- return http_client_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
+ return http_client_read_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
&& getByteOutputReadCallback()
&& getByteOutputReadCallback()->getSize() == 0
&& getByteOutputReadCallback()->waitingOps();
}
Review Comment:
Updated in https://github.com/apache/nifi-minifi-cpp/pull/2094/commits/532063b0141955af8e2bf52f29253a9a56082697
##########
core-framework/include/http/HTTPStream.h:
##########
@@ -114,19 +102,16 @@ class HttpStream : public io::BaseStreamImpl {
}
inline bool isFinished(int seconds = 0) {
- return http_client_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
+ return http_client_read_future_.wait_for(std::chrono::seconds(seconds)) == std::future_status::ready
&& getByteOutputReadCallback()
&& getByteOutputReadCallback()->getSize() == 0
&& getByteOutputReadCallback()->waitingOps();
}
- /**
- * Waits for more data to become available.
- */
bool waitForDataAvailable() {
do {
logger_->log_trace("Waiting for more data");
- } while (http_client_future_.wait_for(std::chrono::seconds(0)) != std::future_status::ready
+ } while (http_client_read_future_.wait_for(std::chrono::seconds(0)) != std::future_status::ready
&& getByteOutputReadCallback()
&& getByteOutputReadCallback()->getSize() == 0);
Review Comment:
Updated in https://github.com/apache/nifi-minifi-cpp/pull/2094/commits/532063b0141955af8e2bf52f29253a9a56082697
##########
libminifi/src/sitetosite/HttpSiteToSiteClient.cpp:
##########
@@ -388,4 +385,33 @@ void HttpSiteToSiteClient::setSiteToSiteHeaders(minifi::http::HTTPClient& client
}
}
+std::pair<uint64_t, uint64_t> HttpSiteToSiteClient::readFlowFiles(const std::shared_ptr<Transaction>& transaction, core::ProcessSession& session) {
+ auto http_stream = dynamic_cast<http::HttpStream*>(peer_->getStream());
+ if (!http_stream) {
+ throw Exception(SITE2SITE_EXCEPTION, "Reading flow files failed: stream cannot be cast to HTTP stream");
+ }
+
+ try {
+ return SiteToSiteClient::readFlowFiles(transaction, session);
+ } catch (const Exception&) {
+ auto response_code = http_stream->getClientRef()->getResponseCode();
+
+ // 200 tells us that there is no content to read, so we should not treat it as an error.
+ // The read fails in this case because the stream does not contain a valid response body with the expected format.
+ // Unfortunately there is no way to get the response code before trying to read, so we have to let it fail and check the response code afterwards.
+ if (response_code == 200) {
+ logger_->log_debug("Response code 200, no content to read");
+ transaction->setDataAvailable(false);
+ transaction->setState(TransactionState::TRANSACTION_CANCELED);
+ current_code_ = ResponseCode::CANCEL_TRANSACTION;
+ return {0, 0};
+ }
+ throw;
+ }
+
+ if (auto response_code = http_stream->getClientRef()->getResponseCode(); response_code >= 400) {
+ throw Exception(SITE2SITE_EXCEPTION, fmt::format("HTTP error code received while reading flow files: {}", response_code));
+ }
+}
Review Comment:
Updated in https://github.com/apache/nifi-minifi-cpp/pull/2094/commits/532063b0141955af8e2bf52f29253a9a56082697
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "lordgamez (via GitHub)" <gi...@apache.org>.
lordgamez commented on code in PR #2094:
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094#discussion_r2799208971
##########
libminifi/src/sitetosite/HttpSiteToSiteClient.cpp:
##########
@@ -388,4 +385,33 @@ void HttpSiteToSiteClient::setSiteToSiteHeaders(minifi::http::HTTPClient& client
}
}
+std::pair<uint64_t, uint64_t> HttpSiteToSiteClient::readFlowFiles(const std::shared_ptr<Transaction>& transaction, core::ProcessSession& session) {
+ auto http_stream = dynamic_cast<http::HttpStream*>(peer_->getStream());
+ if (!http_stream) {
+ throw Exception(SITE2SITE_EXCEPTION, "Reading flow files failed: stream cannot be cast to HTTP stream");
+ }
+
+ try {
+ return SiteToSiteClient::readFlowFiles(transaction, session);
+ } catch (const Exception&) {
+ auto response_code = http_stream->getClientRef()->getResponseCode();
+
+ // 200 tells us that there is no content to read, so we should not treat it as an error.
+ // The read fails in this case because the stream does not contain a valid response body with the expected format.
+ // Unfortunately there is no way to get the response code before trying to read, so we have to let it fail and check the response code afterwards.
+ if (response_code == 200) {
+ logger_->log_debug("Response code 200, no content to read");
+ transaction->setDataAvailable(false);
+ transaction->setState(TransactionState::TRANSACTION_CANCELED);
+ current_code_ = ResponseCode::CANCEL_TRANSACTION;
+ return {0, 0};
+ }
Review Comment:
This is already tested manually and in the docker integration tests.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] MINIFICPP-2709 Fix site to site receive using HTTP protocol [nifi-minifi-cpp]
Posted by "szaszm (via GitHub)" <gi...@apache.org>.
szaszm closed pull request #2094: MINIFICPP-2709 Fix site to site receive using HTTP protocol
URL: https://github.com/apache/nifi-minifi-cpp/pull/2094
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@nifi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org