szaszm commented on code in PR #1038:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1038#discussion_r921864633
##########
libminifi/src/core/yaml/YamlConnectionParser.cpp:
##########
@@ -97,7 +97,21 @@ uint64_t
YamlConnectionParser::getWorkQueueDataSizeFromYaml() const {
logger_->log_debug("Setting %" PRIu64 "as the max as the max queue data
size.", max_work_queue_data_size);
return max_work_queue_data_size;
}
- logger_->log_info("Invalid max queue data size value: %s.",
max_work_queue_str);
+ logger_->log_error("Invalid max queue data size value: %s.",
max_work_queue_str);
+ }
+ return 0;
+}
+
+uint64_t YamlConnectionParser::getSwapThresholdFromYaml() const {
+ const YAML::Node swap_threshold_node = connectionNode_["swap threshold"];
+ if (swap_threshold_node) {
+ auto swap_threshold_str = swap_threshold_node.as<std::string>();
+ uint64_t swap_threshold;
+ if (core::Property::StringToInt(swap_threshold_str, swap_threshold)) {
+ logger_->log_debug("Setting %" PRIu64 " as the swap threshold.",
swap_threshold);
+ return swap_threshold;
+ }
+ logger_->log_error("Invalid swap threshold value: %s.",
swap_threshold_str);
Review Comment:
I think it would make sense to have a reasonable default value. I would go
for a third of the connection size. Is this in bytes or the number of flow
files?
Unrelated, but I was also thinking about reducing default connection queue
size limits, because 10k flow files is a bit excessive IMO, 1k-2k would be more
reasonable.
##########
extensions/rocksdb-repos/FlowFileLoader.cpp:
##########
@@ -0,0 +1,112 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "FlowFileLoader.h"
+
+#include <span>
+#include <memory>
+#include <string>
+#include <vector>
+#include <utility>
+
+#include "logging/LoggerConfiguration.h"
+#include "FlowFileRecord.h"
+
+namespace org::apache::nifi::minifi {
+
+FlowFileLoader::FlowFileLoader()
+ : logger_(core::logging::LoggerFactory<FlowFileLoader>::getLogger()) {}
+
+FlowFileLoader::~FlowFileLoader() {
+ stop();
+}
+
+void FlowFileLoader::initialize(gsl::not_null<minifi::internal::RocksDatabase
*> db, std::shared_ptr<core::ContentRepository> content_repo) {
+ db_ = db;
+ content_repo_ = std::move(content_repo);
+}
+
+std::future<FlowFileLoader::FlowFilePtrVec>
FlowFileLoader::load(std::vector<SwappedFlowFile> flow_files) {
+ auto promise = std::make_shared<std::promise<FlowFilePtrVec>>();
+ std::future<FlowFilePtrVec> future = promise->get_future();
+ utils::Worker<utils::TaskRescheduleInfo> task{
+ std::bind(&FlowFileLoader::loadImpl, this, std::move(flow_files),
std::move(promise)),
+ "", // doesn't matter that tasks alias by name, as we never actually
query their status or stop a single task
+ std::make_unique<utils::ComplexMonitor>()};
+ std::future<utils::TaskRescheduleInfo> dummy_future;
+ thread_pool_.execute(std::move(task), dummy_future);
+ return future;
Review Comment:
I feel like this is hacking around the added complexity of using ThreadPool.
Why not use utils::FifoExecutor? I may be biased, since I wrote FifoExecutor,
but it's meant to solve this exact problem: You give it a function of T, and it
gives back a future of T.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
