[jira] [Updated] (NIFI-11532) Remove JUnit 4 and Groovy Test from Default Dependencies
[ https://issues.apache.org/jira/browse/NIFI-11532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11532: Status: Patch Available (was: Open) > Remove JUnit 4 and Groovy Test from Default Dependencies > > > Key: NIFI-11532 > URL: https://issues.apache.org/jira/browse/NIFI-11532 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.latest > > Time Spent: 10m > Remaining Estimate: 0h > > The root Maven configuration includes JUnit 4 in the list of default project > dependencies. With the vast majority of tests migrated to JUnit 5, JUnit 4 > should be removed from the set of default project dependencies. This includes > removing the JUnit Vintage Engine dependency, which provides compatibility > for JUnit 4. The few remaining modules with JUnit 4 tests should have > declared dependencies on the JUnit Vintage Engine to highlight remaining > items for refactoring. > Following a similar pattern, the Groovy Test dependency should be removed > from the list of default project dependencies. the Groovy Test module should > be added to the modules with remaining Groovy tests to highlight additional > work needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] exceptionfactory opened a new pull request, #7233: NIFI-11532 Remove JUnit 4 and Groovy Test from default dependencies
exceptionfactory opened a new pull request, #7233: URL: https://github.com/apache/nifi/pull/7233 # Summary [NIFI-11532](https://issues.apache.org/jira/browse/NIFI-11532) Removes JUnit 4 and Groovy Test modules from the list of default dependencies in the project root configuration, and also removes the Hamcrest dependency from default dependencies. These changes highlight the extensive work completed to migrate the vast majority of tests to JUnit 5 and Java, leaving a small number of modules and classes on JUnit 4 and Groovy. Removing JUnit 4 and Groovy Test dependencies from the list of defaults helps avoid introducing JUnit 4 and Groovy code in new modules. A small number of modules with remaining dependencies on JUnit 4 and Groovy have declared dependencies on the JUnit Vintage Engine and the Groovy Test library. Additional changes include removing several unnecessary test classes from `nifi-socket-utils`, removing duplicative Registry toolkit tests, and removing the integration test classes from the NiFI Kudu module. # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [X] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [X] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [X] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [X] Pull Request based on current revision of the `main` branch - [X] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [X] Build completed using `mvn clean install -P contrib-check` - [X] JDK 11 - [ ] JDK 17 ### Licensing - [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (NIFI-11532) Remove JUnit 4 and Groovy Test from Default Dependencies
David Handermann created NIFI-11532: --- Summary: Remove JUnit 4 and Groovy Test from Default Dependencies Key: NIFI-11532 URL: https://issues.apache.org/jira/browse/NIFI-11532 Project: Apache NiFi Issue Type: Sub-task Reporter: David Handermann Assignee: David Handermann Fix For: 2.latest The root Maven configuration includes JUnit 4 in the list of default project dependencies. With the vast majority of tests migrated to JUnit 5, JUnit 4 should be removed from the set of default project dependencies. This includes removing the JUnit Vintage Engine dependency, which provides compatibility for JUnit 4. The few remaining modules with JUnit 4 tests should have declared dependencies on the JUnit Vintage Engine to highlight remaining items for refactoring. Following a similar pattern, the Groovy Test dependency should be removed from the list of default project dependencies. the Groovy Test module should be added to the modules with remaining Groovy tests to highlight additional work needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] mtien-apache commented on a diff in pull request #7117: NIFI-11287: detect dependent properties when the property it depends on references a parameter (UI)
mtien-apache commented on code in PR #7117:
URL: https://github.com/apache/nifi/pull/7117#discussion_r1187988754
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/jquery/propertytable/jquery.propertytable.js:
##
@@ -1931,13 +1948,20 @@
if (property.hidden === false) {
// Get the property value by propertyName
var propertyValue =
properties[dependency.propertyName];
+referencingParameter = null;
+
+// check if the property references a
parameter
+if (!_.isEmpty(currentParameterContext)) {
Review Comment:
@mcgilman Thanks for reviewing! I removed the `type` parameters and updated
to use the provided callbacks from the client when calling `loadProperties`.
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (NIFI-11528) Refactor Groovy tests in nifi-commons/nifi-utils to Java (and JUnit 5)
[ https://issues.apache.org/jira/browse/NIFI-11528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720696#comment-17720696 ] David Handermann commented on NIFI-11528: - The Groovy files should be deleted, that will be visible as part of the pull request for comparison. If there are any Maven configuration dependencies for Groovy, those could also be removed from the module. > Refactor Groovy tests in nifi-commons/nifi-utils to Java (and JUnit 5) > -- > > Key: NIFI-11528 > URL: https://issues.apache.org/jira/browse/NIFI-11528 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Daniel Stieglitz >Assignee: Daniel Stieglitz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11528) Refactor Groovy tests in nifi-commons/nifi-utils to Java (and JUnit 5)
[ https://issues.apache.org/jira/browse/NIFI-11528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720689#comment-17720689 ] Daniel Stieglitz commented on NIFI-11528: - [~exceptionfactory] As part of the PR for this should I delete the actual Groovy file(s) or should I keep them for the reviewer to compare and they will delete them after the PR is accepted? > Refactor Groovy tests in nifi-commons/nifi-utils to Java (and JUnit 5) > -- > > Key: NIFI-11528 > URL: https://issues.apache.org/jira/browse/NIFI-11528 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Daniel Stieglitz >Assignee: Daniel Stieglitz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11531) Refactor Groovy tests in nifi-security-utils to Java
Emilio Setiadarma created NIFI-11531: Summary: Refactor Groovy tests in nifi-security-utils to Java Key: NIFI-11531 URL: https://issues.apache.org/jira/browse/NIFI-11531 Project: Apache NiFi Issue Type: Sub-task Reporter: Emilio Setiadarma Assignee: Emilio Setiadarma Refactoring groovy tests in nifi-security-utils module to Java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11392) NiFi does not stop timely when using CRON scheduling
[ https://issues.apache.org/jira/browse/NIFI-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720660#comment-17720660 ] Michael W Moser commented on NIFI-11392: This same behavior also happens with CRON scheduled reporting tasks. The PR resolves this, too. > NiFi does not stop timely when using CRON scheduling > > > Key: NIFI-11392 > URL: https://issues.apache.org/jira/browse/NIFI-11392 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.21.0 >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > When using CRON scheduling on at least 1 processor in a flow, and any CRON > driven processor has been scheduled at least once, then NiFi does not stop > within the graceful.shutdown.seconds period and has to be killed. If > possible it would be nice to clean this up. > I setup GenerateFlowFile with a CRON schedule of "0 * * * * ?". After it has > run once, I stopped NiFi and it was killed after 20 seconds instead of > stopping in 2 or 3 seconds. > 2023-04-06 14:58:07,495 INFO [main] org.apache.nifi.bootstrap.Command Apache > NiFi has accepted the Shutdown Command and is shutting down now > ... > 2023-04-06 14:58:27,924 INFO [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown in progress... > 2023-04-06 14:58:27,953 WARN [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown not completed after 20 seconds: Killing process > 2023-04-06 14:58:27,985 INFO [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown completed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11392) NiFi does not stop timely when using CRON scheduling
[ https://issues.apache.org/jira/browse/NIFI-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael W Moser updated NIFI-11392: --- Affects Version/s: 1.21.0 (was: 1.20.0) Status: Patch Available (was: In Progress) > NiFi does not stop timely when using CRON scheduling > > > Key: NIFI-11392 > URL: https://issues.apache.org/jira/browse/NIFI-11392 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.21.0 >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > When using CRON scheduling on at least 1 processor in a flow, and any CRON > driven processor has been scheduled at least once, then NiFi does not stop > within the graceful.shutdown.seconds period and has to be killed. If > possible it would be nice to clean this up. > I setup GenerateFlowFile with a CRON schedule of "0 * * * * ?". After it has > run once, I stopped NiFi and it was killed after 20 seconds instead of > stopping in 2 or 3 seconds. > 2023-04-06 14:58:07,495 INFO [main] org.apache.nifi.bootstrap.Command Apache > NiFi has accepted the Shutdown Command and is shutting down now > ... > 2023-04-06 14:58:27,924 INFO [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown in progress... > 2023-04-06 14:58:27,953 WARN [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown not completed after 20 seconds: Killing process > 2023-04-06 14:58:27,985 INFO [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown completed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-11392) NiFi does not stop timely when using CRON scheduling
[ https://issues.apache.org/jira/browse/NIFI-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael W Moser reassigned NIFI-11392: -- Assignee: Michael W Moser > NiFi does not stop timely when using CRON scheduling > > > Key: NIFI-11392 > URL: https://issues.apache.org/jira/browse/NIFI-11392 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.20.0 >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > When using CRON scheduling on at least 1 processor in a flow, and any CRON > driven processor has been scheduled at least once, then NiFi does not stop > within the graceful.shutdown.seconds period and has to be killed. If > possible it would be nice to clean this up. > I setup GenerateFlowFile with a CRON schedule of "0 * * * * ?". After it has > run once, I stopped NiFi and it was killed after 20 seconds instead of > stopping in 2 or 3 seconds. > 2023-04-06 14:58:07,495 INFO [main] org.apache.nifi.bootstrap.Command Apache > NiFi has accepted the Shutdown Command and is shutting down now > ... > 2023-04-06 14:58:27,924 INFO [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown in progress... > 2023-04-06 14:58:27,953 WARN [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown not completed after 20 seconds: Killing process > 2023-04-06 14:58:27,985 INFO [main] org.apache.nifi.bootstrap.Command NiFi > PID [4625] shutdown completed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] mosermw opened a new pull request, #7232: NIFI-11392 for CRON scheduled components, improved cancellation of …
mosermw opened a new pull request, #7232: URL: https://github.com/apache/nifi/pull/7232 …futures for thread cleanup # Summary [NIFI-11392](https://issues.apache.org/jira/browse/NIFI-11392) # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [x] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [x] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [x] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [x] Pull Request based on current revision of the `main` branch - [x] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [x] JDK 11 - [ ] JDK 17 ### Licensing - [n/a] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [n/a] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] fgerlits commented on a diff in pull request #1560: MINIFICPP-2101 Compilation fix in PutSFTPTests (libc++)
fgerlits commented on code in PR #1560:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1560#discussion_r1187625625
##
libminifi/test/unit/FileUtilsTests.cpp:
##
@@ -516,3 +516,38 @@ TEST_CASE("FileUtils::path_size", "[TestPathSize]") {
REQUIRE(FileUtils::path_size(dir) == 12);
}
+
+TEST_CASE("file_clock to system_clock conversion tests") {
+ using namespace std::chrono;
+
+ static_assert(system_clock::period::num == file_clock::period::num);
+ constexpr auto lowest_den = std::min(file_clock::period::den,
system_clock::period::den);
+ using LeastPreciseDurationType =
duration, std::ratio>;
+
+ {
+system_clock::time_point system_now = system_clock::now();
+file_clock::time_point converted_system_now =
FileUtils::from_sys(system_now);
+system_clock::time_point double_converted_system_now =
FileUtils::to_sys(converted_system_now);
+
+
CHECK(time_point_cast(system_now).time_since_epoch().count()
==
time_point_cast(double_converted_system_now).time_since_epoch().count());
+ }
+
+ {
+file_clock::time_point file_now = file_clock ::now();
+system_clock::time_point converted_file_now = FileUtils::to_sys(file_now);
+file_clock::time_point double_converted_file_now =
FileUtils::from_sys(converted_file_now);
+
+
CHECK(time_point_cast(file_now).time_since_epoch().count()
==
time_point_cast(double_converted_file_now).time_since_epoch().count());
+ }
+
+ {
+system_clock::time_point system_now = system_clock::now();
+file_clock::time_point file_now = file_clock ::now();
+
+file_clock::time_point converted_system_now =
FileUtils::from_sys(system_now);
+system_clock::time_point converted_file_now = FileUtils::to_sys(file_now);
+
+CHECK(system_now-converted_file_now < 10ms);
Review Comment:
This doesn't really test what we want to test, because `system_now -
converted_file_now` is either zero or negative. The reverse should be OK:
```c++
CHECK(converted_file_now - system_now < 10ms);
```
or, better:
```c++
CHECK(0ms <= converted_file_now - system_now);
CHECK(converted_file_now - system_now < 10ms);
```
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] lordgamez commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
lordgamez commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1187591401
##
libminifi/src/FlowController.cpp:
##
@@ -127,35 +127,34 @@ bool FlowController::applyConfiguration(const std::string
, const std::st
logger_->log_info("Starting to reload Flow Controller with flow control name
%s, version %d", newRoot->getName(), newRoot->getVersion());
- updating_.beginUpdate();
bool started = false;
-
{
-std::lock_guard flow_lock(mutex_);
-stop();
-
-root_wrapper_.setNewRoot(std::move(newRoot));
-initialized_ = false;
-try {
- load(true);
- started = start() == 0;
-} catch (const std::exception& ex) {
- logger_->log_error("Caught exception while starting flow, type %s, what:
%s", typeid(ex).name(), ex.what());
-} catch (...) {
- logger_->log_error("Caught unknown exception while starting flow, type
%s", getCurrentExceptionTypeName());
-}
-if (!started) {
- logger_->log_error("Failed to start new flow, restarting previous flow");
- root_wrapper_.restoreBackup();
- load(true);
- start();
-} else {
- root_wrapper_.clearBackup();
+auto update_lock = updating_.getUpdateLock();
+{
+ std::lock_guard flow_lock(mutex_);
Review Comment:
Updated in 1fd1685fbccb60386133baeee87ddcffa4747487
##
libminifi/include/FlowController.h:
##
@@ -149,6 +149,34 @@ class FlowController : public
core::controller::ForwardingControllerServiceProvi
std::map> getDebugInfo()
override;
private:
+ class UpdateState {
+class UpdateLock;
+ public:
+UpdateLock getUpdateLock() { return UpdateLock(*this); }
+bool isUpdating() const { return update_block_count_ > 0; }
+
+ private:
+class UpdateLock {
+ public:
+ UpdateLock(UpdateState& update_state) : update_state_(update_state) {
+update_state_.beginUpdate();
+ }
+
+ ~UpdateLock() {
+update_state_.endUpdate();
+ }
+ private:
+ UpdateState& update_state_;
+};
+
Review Comment:
The latter sounds good, thanks, updated in
1fd1685fbccb60386133baeee87ddcffa4747487
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] exceptionfactory commented on pull request #7231: [NIFI-2964] Added ability for AttributeToJSON to handle nested JSON when outputting to a flow file.
exceptionfactory commented on PR #7231: URL: https://github.com/apache/nifi/pull/7231#issuecomment-1538488016 Thanks @dan-s1, it's fine for now, if you end up making additional changes before further review, that squashing commits sounds good, otherwise it looks good for now. -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] dan-s1 commented on pull request #7231: [NIFI-2964] Added ability for AttributeToJSON to handle nested JSON when outputting to a flow file.
dan-s1 commented on PR #7231: URL: https://github.com/apache/nifi/pull/7231#issuecomment-1538483399 @exceptionfactory I looked over my code since last Friday's initial commit and I realized there were other things that needed to be added so I have added 2 other commits. I believe for my PR for NIFI-11167 I squashed too much when I had to make changes. For this PR would you like me to squash these or should I leave this as is? -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
szaszm commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1187532598
##
libminifi/include/FlowController.h:
##
@@ -149,6 +149,34 @@ class FlowController : public
core::controller::ForwardingControllerServiceProvi
std::map> getDebugInfo()
override;
private:
+ class UpdateState {
+class UpdateLock;
+ public:
+UpdateLock getUpdateLock() { return UpdateLock(*this); }
+bool isUpdating() const { return update_block_count_ > 0; }
+
+ private:
+class UpdateLock {
+ public:
+ UpdateLock(UpdateState& update_state) : update_state_(update_state) {
+update_state_.beginUpdate();
+ }
+
+ ~UpdateLock() {
+update_state_.endUpdate();
+ }
+ private:
+ UpdateState& update_state_;
+};
+
Review Comment:
Please check the rule of 5 for this class. I think copying the object will
result in double decrease and underflowing update count.
Alternatively, you could remove this class, keep the
`beginUpdate`/`endUpdate` functionality public, add aliases as `lock`/`unlock`,
and use `std::scoped_lock` on the `UpdateState`
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
szaszm commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1187532598
##
libminifi/include/FlowController.h:
##
@@ -149,6 +149,34 @@ class FlowController : public
core::controller::ForwardingControllerServiceProvi
std::map> getDebugInfo()
override;
private:
+ class UpdateState {
+class UpdateLock;
+ public:
+UpdateLock getUpdateLock() { return UpdateLock(*this); }
+bool isUpdating() const { return update_block_count_ > 0; }
+
+ private:
+class UpdateLock {
+ public:
+ UpdateLock(UpdateState& update_state) : update_state_(update_state) {
+update_state_.beginUpdate();
+ }
+
+ ~UpdateLock() {
+update_state_.endUpdate();
+ }
+ private:
+ UpdateState& update_state_;
+};
+
Review Comment:
Please check the rule of 5 for this class. I think copying the object will
result in double decrease and underflowing update count.
Alternatively, you could keep the `beginUpdate`/`endUpdate` functionality
public, add aliases as `lock`/`unlock`, and use `std::scoped_lock` on the
`UpdateState`
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
szaszm commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1187532598
##
libminifi/include/FlowController.h:
##
@@ -149,6 +149,34 @@ class FlowController : public
core::controller::ForwardingControllerServiceProvi
std::map> getDebugInfo()
override;
private:
+ class UpdateState {
+class UpdateLock;
+ public:
+UpdateLock getUpdateLock() { return UpdateLock(*this); }
+bool isUpdating() const { return update_block_count_ > 0; }
+
+ private:
+class UpdateLock {
+ public:
+ UpdateLock(UpdateState& update_state) : update_state_(update_state) {
+update_state_.beginUpdate();
+ }
+
+ ~UpdateLock() {
+update_state_.endUpdate();
+ }
+ private:
+ UpdateState& update_state_;
+};
+
Review Comment:
Please check the rule of 5 for this class. I think copying the object will
result in double decrease and underflowing update count.
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
szaszm commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1187528318
##
libminifi/src/FlowController.cpp:
##
@@ -127,35 +127,34 @@ bool FlowController::applyConfiguration(const std::string
, const std::st
logger_->log_info("Starting to reload Flow Controller with flow control name
%s, version %d", newRoot->getName(), newRoot->getVersion());
- updating_.beginUpdate();
bool started = false;
-
{
-std::lock_guard flow_lock(mutex_);
-stop();
-
-root_wrapper_.setNewRoot(std::move(newRoot));
-initialized_ = false;
-try {
- load(true);
- started = start() == 0;
-} catch (const std::exception& ex) {
- logger_->log_error("Caught exception while starting flow, type %s, what:
%s", typeid(ex).name(), ex.what());
-} catch (...) {
- logger_->log_error("Caught unknown exception while starting flow, type
%s", getCurrentExceptionTypeName());
-}
-if (!started) {
- logger_->log_error("Failed to start new flow, restarting previous flow");
- root_wrapper_.restoreBackup();
- load(true);
- start();
-} else {
- root_wrapper_.clearBackup();
+auto update_lock = updating_.getUpdateLock();
+{
+ std::lock_guard flow_lock(mutex_);
Review Comment:
The inner scope is not necessary here, the two locks could just follow each
other.
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] lordgamez commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
lordgamez commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1187524994
##
libminifi/include/FlowController.h:
##
@@ -149,6 +149,22 @@ class FlowController : public
core::controller::ForwardingControllerServiceProvi
std::map> getDebugInfo()
override;
private:
+ class UpdateState {
+ public:
+void beginUpdate() {
+ ++update_block_count_;
+}
+void endUpdate() {
+ --update_block_count_;
+}
+bool isUpdating() const {
+ return update_block_count_ > 0;
+}
+
+ private:
+std::atomic update_block_count_;
+ };
+
Review Comment:
Good point, added a scoped UpdateLock in
ffefd48806fffcc07dbbff20d1159e206e19824f
##
docker/test/integration/features/CMakeLists.txt:
##
@@ -87,6 +87,10 @@ if (ENABLE_PROMETHEUS)
set(ENABLED_BEHAVE_TESTS
"${ENABLED_BEHAVE_TESTS};${CMAKE_CURRENT_SOURCE_DIR}/prometheus.feature")
endif()
+if (NOT DISABLE_CURL AND NOT DISABLE_CONTROLLER)
+set(ENABLED_BEHAVE_TESTS
"${ENABLED_BEHAVE_TESTS};${CMAKE_CURRENT_SOURCE_DIR}/minifi_controller.feature")
Review Comment:
Updated in ffefd48806fffcc07dbbff20d1159e206e19824f
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] lordgamez commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
lordgamez commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1185114953
##
controller/tests/ControllerTests.cpp:
##
@@ -314,14 +314,14 @@ TEST_CASE_METHOD(ControllerTestFixture, "Test
listComponents", "[controllerTests
}
using org::apache::nifi::minifi::utils::verifyEventHappenedInPollTime;
- REQUIRE(verifyEventHappenedInPollTime(500ms, [&] { return
controller_->isRunning(); }, 20ms));
+ REQUIRE(verifyEventHappenedInPollTime(5s, [&] { return
controller_->isRunning(); }, 20ms));
Review Comment:
Sometimes these checks were flaky in the CI probably due to the introduced
communication of the command handlings threads through the `ConcurrentQueue`.
10 times is probably an overkill as it should probably be under 2 seconds in
the CI as well, but I wanted to make sure to remove the flakyness and only test
the functionality.
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (NIFI-11385) Expose JMX metrics from NiFi JVM
[ https://issues.apache.org/jira/browse/NIFI-11385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11385: Fix Version/s: 2.0.0 1.22.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Expose JMX metrics from NiFi JVM > > > Key: NIFI-11385 > URL: https://issues.apache.org/jira/browse/NIFI-11385 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Timea Barna >Assignee: Timea Barna >Priority: Major > Fix For: 2.0.0, 1.22.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Most of the NiFi processors use external libraries which may register JMX > Beans like Kafka processors. Exposing such metrics can help with problem > solving. > The information available depends on the registered Beans and usually related > to performance indicators such as request/response rate, latency, request > size, request counts or tool specific ones like commit rate or sync/join time > for Kafka. > Goals > Have an REST endpoint with a list of JMX Bean attributes. > Expose data in a secure way. > Have some kind of filtering. > Non-Goals > Listing or executing supported operations of JMX Beans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11385) Expose JMX metrics from NiFi JVM
[ https://issues.apache.org/jira/browse/NIFI-11385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11385: Issue Type: New Feature (was: Improvement) > Expose JMX metrics from NiFi JVM > > > Key: NIFI-11385 > URL: https://issues.apache.org/jira/browse/NIFI-11385 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Timea Barna >Assignee: Timea Barna >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Most of the NiFi processors use external libraries which may register JMX > Beans like Kafka processors. Exposing such metrics can help with problem > solving. > The information available depends on the registered Beans and usually related > to performance indicators such as request/response rate, latency, request > size, request counts or tool specific ones like commit rate or sync/join time > for Kafka. > Goals > Have an REST endpoint with a list of JMX Bean attributes. > Expose data in a secure way. > Have some kind of filtering. > Non-Goals > Listing or executing supported operations of JMX Beans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11385) Expose JMX metrics from NiFi JVM
[ https://issues.apache.org/jira/browse/NIFI-11385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720501#comment-17720501 ] ASF subversion and git services commented on NIFI-11385: Commit e1ddc44b078b17780465c6075e4bdd51ac522c89 in nifi's branch refs/heads/support/nifi-1.x from Timea Barna [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e1ddc44b07 ] NIFI-11385 Added JMX Metrics REST Resource for Diagnostics This closes #7124 Co-authored-by: David Handermann Signed-off-by: David Handermann (cherry picked from commit 5811a9c579a11aa8fc8358851df33d0456a5e10c) > Expose JMX metrics from NiFi JVM > > > Key: NIFI-11385 > URL: https://issues.apache.org/jira/browse/NIFI-11385 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Timea Barna >Assignee: Timea Barna >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Most of the NiFi processors use external libraries which may register JMX > Beans like Kafka processors. Exposing such metrics can help with problem > solving. > The information available depends on the registered Beans and usually related > to performance indicators such as request/response rate, latency, request > size, request counts or tool specific ones like commit rate or sync/join time > for Kafka. > Goals > Have an REST endpoint with a list of JMX Bean attributes. > Expose data in a secure way. > Have some kind of filtering. > Non-Goals > Listing or executing supported operations of JMX Beans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11385) Expose JMX metrics from NiFi JVM
[ https://issues.apache.org/jira/browse/NIFI-11385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720500#comment-17720500 ] ASF subversion and git services commented on NIFI-11385: Commit 5811a9c579a11aa8fc8358851df33d0456a5e10c in nifi's branch refs/heads/main from Timea Barna [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5811a9c579 ] NIFI-11385 Added JMX Metrics REST Resource for Diagnostics This closes #7124 Co-authored-by: David Handermann Signed-off-by: David Handermann > Expose JMX metrics from NiFi JVM > > > Key: NIFI-11385 > URL: https://issues.apache.org/jira/browse/NIFI-11385 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Timea Barna >Assignee: Timea Barna >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Most of the NiFi processors use external libraries which may register JMX > Beans like Kafka processors. Exposing such metrics can help with problem > solving. > The information available depends on the registered Beans and usually related > to performance indicators such as request/response rate, latency, request > size, request counts or tool specific ones like commit rate or sync/join time > for Kafka. > Goals > Have an REST endpoint with a list of JMX Bean attributes. > Expose data in a secure way. > Have some kind of filtering. > Non-Goals > Listing or executing supported operations of JMX Beans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] exceptionfactory closed pull request #7124: NIFI-11385 Expose JMX metrics from NiFi JVM
exceptionfactory closed pull request #7124: NIFI-11385 Expose JMX metrics from NiFi JVM URL: https://github.com/apache/nifi/pull/7124 -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MINIFICPP-2103) JNI extension fails to compile (libc++)
[ https://issues.apache.org/jira/browse/MINIFICPP-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zink updated MINIFICPP-2103: --- Resolution: Fixed Status: Resolved (was: Patch Available) https://github.com/apache/nifi-minifi-cpp/commit/72e1c35164ab19137fc19396f902536c625584a5 > JNI extension fails to compile (libc++) > --- > > Key: MINIFICPP-2103 > URL: https://issues.apache.org/jira/browse/MINIFICPP-2103 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Martin Zink >Assignee: Martin Zink >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > extensions/jni/jvm/JniReferenceObjects.h:112:86: error: no matching function > for call to 'min' > int actual = > static_cast(stream_->read(gsl::make_span(buffer_).subspan(0, > std::min(remaining, buffer_.size(); > > > ^~~~ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi-minifi-cpp] martinzink commented on pull request #1566: MINIFICPP-2109 - Add extra logs to configuration parsing
martinzink commented on PR #1566: URL: https://github.com/apache/nifi-minifi-cpp/pull/1566#issuecomment-1538208243 There are some clang-tidy warning you should check out, otherwise LGTM -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] martinzink commented on pull request #1566: MINIFICPP-2109 - Add extra logs to configuration parsing
martinzink commented on PR #1566: URL: https://github.com/apache/nifi-minifi-cpp/pull/1566#issuecomment-1538200554 There are some clang-tidy warning you should check out, otherwise LGTM -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a diff in pull request #1568: MINIFICPP-2112 Fix flow update and restart with minifi controller
szaszm commented on code in PR #1568:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1568#discussion_r1187114195
##
docker/test/integration/features/CMakeLists.txt:
##
@@ -87,6 +87,10 @@ if (ENABLE_PROMETHEUS)
set(ENABLED_BEHAVE_TESTS
"${ENABLED_BEHAVE_TESTS};${CMAKE_CURRENT_SOURCE_DIR}/prometheus.feature")
endif()
+if (NOT DISABLE_CURL AND NOT DISABLE_CONTROLLER)
+set(ENABLED_BEHAVE_TESTS
"${ENABLED_BEHAVE_TESTS};${CMAKE_CURRENT_SOURCE_DIR}/minifi_controller.feature")
Review Comment:
`list(APPEND` would be more descriptive
##
libminifi/include/FlowController.h:
##
@@ -149,6 +149,22 @@ class FlowController : public
core::controller::ForwardingControllerServiceProvi
std::map> getDebugInfo()
override;
private:
+ class UpdateState {
+ public:
+void beginUpdate() {
+ ++update_block_count_;
+}
+void endUpdate() {
+ --update_block_count_;
+}
+bool isUpdating() const {
+ return update_block_count_ > 0;
+}
+
+ private:
+std::atomic update_block_count_;
+ };
+
Review Comment:
A scoped solution would be better in that it's impossible to forget closing
an opened update block. Maybe we could even use std::scoped_lock to track
update blocks.
--
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-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (NIFI-11530) Disk full even with nifi.content.repository.archive.max.usage.percentage set to 50%
Giovanni created NIFI-11530: --- Summary: Disk full even with nifi.content.repository.archive.max.usage.percentage set to 50% Key: NIFI-11530 URL: https://issues.apache.org/jira/browse/NIFI-11530 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.20.0 Environment: Ubuntu 20.04.5 LTS Reporter: Giovanni Attachments: nifi_bug.jpg Nifi primary node reports disk full causing all nodes to stop working. Restarting nifi service does not resolve. Restarting the VM does not resolve. The only way to fix is to clean te content_repository dir: rm -rf ./nifi/content_repository/* Unfortunately I have no logs of the issue ongoing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-2114) Docker tests fail with docker-py dependency issue
[
https://issues.apache.org/jira/browse/MINIFICPP-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gábor Gyimesi resolved MINIFICPP-2114.
--
Fix Version/s: 0.15.0
Resolution: Fixed
> Docker tests fail with docker-py dependency issue
> --
>
> Key: MINIFICPP-2114
> URL: https://issues.apache.org/jira/browse/MINIFICPP-2114
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
>Reporter: Gábor Gyimesi
>Assignee: Gábor Gyimesi
>Priority: Major
> Fix For: 0.15.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Docker tests fail in CI with the following error:
> {code:java}
> docker.errors.DockerException: Error while fetching server API version:
> request() got an unexpected keyword argument 'chunked' {code}
> The root cause of the issue seem to be a dependency issue with thew latest
> version of the requests library (0.29.0), more information about the issue
> can be found here:
> [https://github.com/docker/docker-py/issues/3113#issuecomment-1527377082]
> While this issue is being resolved in docker-py the workaround is to set the
> required version to less than 0.29.0:
> {code:java}
> requests<2.29 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi-minifi-cpp] fgerlits closed pull request #1571: MINIFICPP-2114 Fix docker-py dependency issue
fgerlits closed pull request #1571: MINIFICPP-2114 Fix docker-py dependency issue URL: https://github.com/apache/nifi-minifi-cpp/pull/1571 -- 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-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
