[jira] [Created] (NIFI-13187) Modernize Nifi Maven Archetypes
Bob Paulin created NIFI-13187: - Summary: Modernize Nifi Maven Archetypes Key: NIFI-13187 URL: https://issues.apache.org/jira/browse/NIFI-13187 Project: Apache NiFi Issue Type: Bug Components: Tools and Build Affects Versions: 2.0.0-M3 Reporter: Bob Paulin * Modernize Nifi's Java archetypes using Immutable Map, List utils * Provide more readable property and relationship names * Provide example of flow file transfer usage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12913) Python venv process failure on Ubuntu does not throw proper exception
[
https://issues.apache.org/jira/browse/NIFI-12913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Paulin updated NIFI-12913:
--
Affects Version/s: 2.0.0-M2
> Python venv process failure on Ubuntu does not throw proper exception
> -
>
> Key: NIFI-12913
> URL: https://issues.apache.org/jira/browse/NIFI-12913
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M2
> Environment: Ubuntu
>Reporter: Bob Paulin
>Priority: Minor
>
> Staring nifi with python extensions on is throwing a NPE in the shutdown
> process that swallows the root issue
> Relevant stack trace:
>
>
> {code:java}
> Caused by: java.lang.NullPointerException: Identifier required
> at java.base/java.util.Objects.requireNonNull(Objects.java:259)
> at
> org.apache.nifi.py4j.logging.StandardLogLevelChangeHandler.removeListener(StandardLogLevelChangeHandler.java:78)
> at
> org.apache.nifi.py4j.PythonProcess.killProcess(PythonProcess.java:364)
> at org.apache.nifi.py4j.PythonProcess.shutdown(PythonProcess.java:360)
> at
> org.apache.nifi.py4j.StandardPythonBridge.shutdown(StandardPythonBridge.java:297)
> at
> org.apache.nifi.py4j.StandardPythonBridge.start(StandardPythonBridge.java:85)
> at
> org.apache.nifi.components.ClassLoaderAwarePythonBridge.start(ClassLoaderAwarePythonBridge.java:52)
> at
> org.apache.nifi.controller.FlowController.(FlowController.java:579)
> at
> org.apache.nifi.controller.FlowController.createStandaloneInstance(FlowController.java:411)
> at
> org.apache.nifi.spring.FlowControllerFactoryBean.getObject(FlowControllerFactoryBean.java:83){code}
>
>
> Suggest at a minimum we need a null check here to let the real exception
> related to the venv install failure come through.
>
> ROOT ISSUE
> The venv install command fails on Ubuntu without first running an install
> command on ubuntu
> EX
>
>
> {code:java}
> apt install python3.10-venv {code}
>
>
> If you run venv without it on some Ubuntu/Deb systems you get:
> {code:java}
> python3 -m venv /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/
> The virtual environment was not created successfully because ensurepip is not
> available. On Debian/Ubuntu systems, you need to install the python3-venv
> package using the following command. apt install python3.10-venv You may need
> to use sudo with that command. After installing the python3-venv package,
> recreate your virtual environment. Failing command:
> /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/bin/python3 {code}
>
> Suggest either reading this process output text as a part of the exception
> handling, sending the process output to the logger for easier debugging.
> The process is exited with a 1 status but the NPE at the top of the issue is
> preventing it from getting logged leaving the user guessing what happened.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12913) Python venv process failure on Ubuntu does not throw proper exception
[
https://issues.apache.org/jira/browse/NIFI-12913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Paulin updated NIFI-12913:
--
Description:
Staring nifi with python extensions on is throwing a NPE in the shutdown
process that swallows the root issue
Relevant stack trace:
{code:java}
Caused by: java.lang.NullPointerException: Identifier required
at java.base/java.util.Objects.requireNonNull(Objects.java:259)
at
org.apache.nifi.py4j.logging.StandardLogLevelChangeHandler.removeListener(StandardLogLevelChangeHandler.java:78)
at
org.apache.nifi.py4j.PythonProcess.killProcess(PythonProcess.java:364)
at org.apache.nifi.py4j.PythonProcess.shutdown(PythonProcess.java:360)
at
org.apache.nifi.py4j.StandardPythonBridge.shutdown(StandardPythonBridge.java:297)
at
org.apache.nifi.py4j.StandardPythonBridge.start(StandardPythonBridge.java:85)
at
org.apache.nifi.components.ClassLoaderAwarePythonBridge.start(ClassLoaderAwarePythonBridge.java:52)
at
org.apache.nifi.controller.FlowController.(FlowController.java:579)
at
org.apache.nifi.controller.FlowController.createStandaloneInstance(FlowController.java:411)
at
org.apache.nifi.spring.FlowControllerFactoryBean.getObject(FlowControllerFactoryBean.java:83){code}
Suggest at a minimum we need a null check here to let the real exception
related to the venv install failure come through.
ROOT ISSUE
The venv install command fails on Ubuntu without first running an install
command on ubuntu
EX
{code:java}
apt install python3.10-venv {code}
If you run venv without it on some Ubuntu/Deb systems you get:
{code:java}
python3 -m venv /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/
The virtual environment was not created successfully because ensurepip is not
available. On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command. apt install python3.10-venv You may need
to use sudo with that command. After installing the python3-venv package,
recreate your virtual environment. Failing command:
/home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/bin/python3 {code}
Suggest either reading this process output text as a part of the exception
handling, sending the process output to the logger for easier debugging.
The process is exited with a 1 status but the NPE at the top of the issue is
preventing it from getting logged leaving the user guessing what happened.
was:
Staring nifi with python extensions on is throwing a NPE in the shutdown
process that swallows the root issue
Relevant stack trace:
```
Caused by: java.lang.NullPointerException: Identifier required
at java.base/java.util.Objects.requireNonNull(Objects.java:259)
at
org.apache.nifi.py4j.logging.StandardLogLevelChangeHandler.removeListener(StandardLogLevelChangeHandler.java:78)
at
org.apache.nifi.py4j.PythonProcess.killProcess(PythonProcess.java:364)
at org.apache.nifi.py4j.PythonProcess.shutdown(PythonProcess.java:360)
at
org.apache.nifi.py4j.StandardPythonBridge.shutdown(StandardPythonBridge.java:297)
at
org.apache.nifi.py4j.StandardPythonBridge.start(StandardPythonBridge.java:85)
at
org.apache.nifi.components.ClassLoaderAwarePythonBridge.start(ClassLoaderAwarePythonBridge.java:52)
at
org.apache.nifi.controller.FlowController.(FlowController.java:579)
at
org.apache.nifi.controller.FlowController.createStandaloneInstance(FlowController.java:411)
at
org.apache.nifi.spring.FlowControllerFactoryBean.getObject(FlowControllerFactoryBean.java:83)
```
Suggest at a minimum we need a null check here to let the real exception
related to the venv install failure come through.
ROOT ISSUE
The venv install command fails on Ubuntu without first running an install
command on ubuntu
EX
```
apt install python3.10-venv
```
```
python3 -m venv /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/
The virtual environment was not created successfully because ensurepip is not
available. On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command. apt install python3.10-venv You may need
to use sudo with that command. After installing the python3-venv package,
recreate your virtual environment. Failing command:
/home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/bin/python3
```
Suggest either reading this process output text as a part of the exception
handling, sending the process output to the logger for easier debugging.
The process is exited with a 1 status but the NPE at the top of the issue is
preventing it from getting logged leaving the user guessing what happened.
> Python venv process failure on Ubuntu does not throw proper exception
> -
>
> Key: NIFI-12913
>
[jira] [Created] (NIFI-12913) Python venv process failure on Ubuntu does not throw proper excepiton
Bob Paulin created NIFI-12913: - Summary: Python venv process failure on Ubuntu does not throw proper excepiton Key: NIFI-12913 URL: https://issues.apache.org/jira/browse/NIFI-12913 Project: Apache NiFi Issue Type: Bug Environment: Ubuntu Reporter: Bob Paulin Staring nifi with python extensions on is throwing a NPE in the shutdown process that swallows the root issue Relevant stack trace: ``` Caused by: java.lang.NullPointerException: Identifier required at java.base/java.util.Objects.requireNonNull(Objects.java:259) at org.apache.nifi.py4j.logging.StandardLogLevelChangeHandler.removeListener(StandardLogLevelChangeHandler.java:78) at org.apache.nifi.py4j.PythonProcess.killProcess(PythonProcess.java:364) at org.apache.nifi.py4j.PythonProcess.shutdown(PythonProcess.java:360) at org.apache.nifi.py4j.StandardPythonBridge.shutdown(StandardPythonBridge.java:297) at org.apache.nifi.py4j.StandardPythonBridge.start(StandardPythonBridge.java:85) at org.apache.nifi.components.ClassLoaderAwarePythonBridge.start(ClassLoaderAwarePythonBridge.java:52) at org.apache.nifi.controller.FlowController.(FlowController.java:579) at org.apache.nifi.controller.FlowController.createStandaloneInstance(FlowController.java:411) at org.apache.nifi.spring.FlowControllerFactoryBean.getObject(FlowControllerFactoryBean.java:83) ``` Suggest at a minimum we need a null check here to let the real exception related to the venv install failure come through. ROOT ISSUE The venv install command fails on Ubuntu without first running an install command on ubuntu EX ``` apt install python3.10-venv ``` ``` python3 -m venv /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/ The virtual environment was not created successfully because ensurepip is not available. On Debian/Ubuntu systems, you need to install the python3-venv package using the following command. apt install python3.10-venv You may need to use sudo with that command. After installing the python3-venv package, recreate your virtual environment. Failing command: /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/bin/python3 ``` Suggest either reading this process output text as a part of the exception handling, sending the process output to the logger for easier debugging. The process is exited with a 1 status but the NPE at the top of the issue is preventing it from getting logged leaving the user guessing what happened. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12913) Python venv process failure on Ubuntu does not throw proper exception
[ https://issues.apache.org/jira/browse/NIFI-12913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Paulin updated NIFI-12913: -- Summary: Python venv process failure on Ubuntu does not throw proper exception (was: Python venv process failure on Ubuntu does not throw proper excepiton) > Python venv process failure on Ubuntu does not throw proper exception > - > > Key: NIFI-12913 > URL: https://issues.apache.org/jira/browse/NIFI-12913 > Project: Apache NiFi > Issue Type: Bug > Environment: Ubuntu >Reporter: Bob Paulin >Priority: Minor > > Staring nifi with python extensions on is throwing a NPE in the shutdown > process that swallows the root issue > Relevant stack trace: > ``` > Caused by: java.lang.NullPointerException: Identifier required > at java.base/java.util.Objects.requireNonNull(Objects.java:259) > at > org.apache.nifi.py4j.logging.StandardLogLevelChangeHandler.removeListener(StandardLogLevelChangeHandler.java:78) > at > org.apache.nifi.py4j.PythonProcess.killProcess(PythonProcess.java:364) > at org.apache.nifi.py4j.PythonProcess.shutdown(PythonProcess.java:360) > at > org.apache.nifi.py4j.StandardPythonBridge.shutdown(StandardPythonBridge.java:297) > at > org.apache.nifi.py4j.StandardPythonBridge.start(StandardPythonBridge.java:85) > at > org.apache.nifi.components.ClassLoaderAwarePythonBridge.start(ClassLoaderAwarePythonBridge.java:52) > at > org.apache.nifi.controller.FlowController.(FlowController.java:579) > at > org.apache.nifi.controller.FlowController.createStandaloneInstance(FlowController.java:411) > at > org.apache.nifi.spring.FlowControllerFactoryBean.getObject(FlowControllerFactoryBean.java:83) > ``` > > Suggest at a minimum we need a null check here to let the real exception > related to the venv install failure come through. > > ROOT ISSUE > The venv install command fails on Ubuntu without first running an install > command on ubuntu > EX > ``` > apt install python3.10-venv > ``` > > ``` > python3 -m venv /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/ > The virtual environment was not created successfully because ensurepip is not > available. On Debian/Ubuntu systems, you need to install the python3-venv > package using the following command. apt install python3.10-venv You may need > to use sudo with that command. After installing the python3-venv package, > recreate your virtual environment. Failing command: > /home/bpaulin/nifi-2.0.0-SNAPSHOT/work/python/bin/python3 > ``` > > Suggest either reading this process output text as a part of the exception > handling, sending the process output to the logger for easier debugging. > The process is exited with a 1 status but the NPE at the top of the issue is > preventing it from getting logged leaving the user guessing what happened. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12891) ElasticSearchClientService fails config verification with Nullpointer before first enable
Bob Paulin created NIFI-12891: - Summary: ElasticSearchClientService fails config verification with Nullpointer before first enable Key: NIFI-12891 URL: https://issues.apache.org/jira/browse/NIFI-12891 Project: Apache NiFi Issue Type: Bug Affects Versions: 2.0.0 Reporter: Bob Paulin If a user clicks the "Verify Properties" button before the ElasticSearchClientService Controller Service is first enabled it fails to verify the connection. This is due to a null pointer that occurs because both the responseEncoding and objectmapper is not set in the verify method before the test. This gives the user the incorrect error that the connection failed even though the connection would have succeed. Recommend managing these variables in the verify method. ``` 2024-03-12 15:36:39,437 WARN [Verify Controller Service Config Thread-1] o.a.n.e.ElasticSearchClientServiceImpl ElasticSearchClientServiceImpl[id=46f88c3f-53ce-3fb6-6014-995ad23028de] Unable to connect to Elasticsearch org.apache.nifi.elasticsearch.ElasticsearchException: java.lang.NullPointerException at org.apache.nifi.elasticsearch.ElasticSearchClientServiceImpl.parseResponse(ElasticSearchClientServiceImpl.java:566) at org.apache.nifi.elasticsearch.ElasticSearchClientServiceImpl.getElasticsearchRoot(ElasticSearchClientServiceImpl.java:329) at org.apache.nifi.elasticsearch.ElasticSearchClientServiceImpl.verifyRootConnection(ElasticSearchClientServiceImpl.java:336) at org.apache.nifi.elasticsearch.ElasticSearchClientServiceImpl.verify(ElasticSearchClientServiceImpl.java:243) at org.apache.nifi.controller.service.StandardControllerServiceNode.verifyConfiguration(StandardControllerServiceNode.java:531) at org.apache.nifi.web.dao.impl.StandardControllerServiceDAO.verifyConfiguration(StandardControllerServiceDAO.java:433) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:751) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:751) at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:703) at org.apache.nifi.web.dao.impl.StandardControllerServiceDAO$$SpringCGLIB$$0.verifyConfiguration() at org.apache.nifi.web.StandardNiFiServiceFacade.performControllerServiceConfigVerification(StandardNiFiServiceFacade.java:2945) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:751) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:751) at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:703) at org.apache.nifi.web.StandardNiFiServiceFacade$$SpringCGLIB$$0.performControllerServiceConfigVerification() at org.apache.nifi.web.api.ControllerServiceResource.lambda$performAsyncConfigVerification$28(ControllerServiceResource.java:1108) at org.apache.nifi.web.api.concurrent.AsyncRequestManager$2.run(AsyncRequestManager.java:119) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at
[jira] [Comment Edited] (NIFI-11859) Nifi in standalone mode is not able to enable EmbeddedHazelcastCacheManager
[
https://issues.apache.org/jira/browse/NIFI-11859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819071#comment-17819071
]
Bob Paulin edited comment on NIFI-11859 at 2/21/24 1:53 PM:
Looks like Hazelcast will enable the MulticastJoiner[1] if autodetect is
enabled. And it is by default [2]. This causes Multicast to be enabled when
this is run locally
{code:java}
2024-02-20 19:14:41,547 INFO [Timer-Driven Process Thread-6]
com.hazelcast.instance.impl.Node [192.168.56.1]:5701 [nifi] [5.3.5] Using
Multicast discovery {code}
By disabling the auto detect this does not happen
[https://github.com/apache/nifi/pull/8440]
I get the following in the logs which I believe is expected.
{code:java}
2024-02-20 19:23:15,870 WARN [Timer-Driven Process Thread-2]
com.hazelcast.instance.impl.Node [192.168.56.1]:5701 [nifi] [5.3.5] No join
method is enabled! Starting standalone. {code}
This should also address the issue above since it appears to be hitting a
usecase where the DiscoveryJoiner is enabled. This should also be suppressed
by autodetect being disabled [3]. This appears to happen in both 1.x and 2.x
[1]
[https://github.com/hazelcast/hazelcast/blob/a3ae01dcbfa32e3b314047506dadf837d54e8e2a/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L946|https://github.com/hazelcast/hazelcast/blob/e3dd651a78e97c6702ce4260e6263d4818fb29b1/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L974]
[2]
[https://github.com/hazelcast/hazelcast/blob/e3dd651a78e97c6702ce4260e6263d4818fb29b1/hazelcast/src/main/java/com/hazelcast/config/AutoDetectionConfig.java#L28]
[3]
https://github.com/hazelcast/hazelcast/blob/a3ae01dcbfa32e3b314047506dadf837d54e8e2a/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L938
was (Author: bob):
Looks like Hazelcast will enable the Multicast Joinger[1] if autodetect is
enabled. And it is by default [2]. This causes Multicast to be enabled when
this is run locally
{code:java}
2024-02-20 19:14:41,547 INFO [Timer-Driven Process Thread-6]
com.hazelcast.instance.impl.Node [192.168.56.1]:5701 [nifi] [5.3.5] Using
Multicast discovery {code}
By disabling the auto detect this does not happen
[https://github.com/apache/nifi/pull/8440]
I get the following in the logs which I believe is expected.
{code:java}
2024-02-20 19:23:15,870 WARN [Timer-Driven Process Thread-2]
com.hazelcast.instance.impl.Node [192.168.56.1]:5701 [nifi] [5.3.5] No join
method is enabled! Starting standalone. {code}
This should also address the issue above since it appears to be hitting a
usecase where the DiscoveryJoiner is enabled. This should also be suppressed
by autodetect being disabled [3]. This appears to happen in both 1.x and 2.x
[1]
[https://github.com/hazelcast/hazelcast/blob/a3ae01dcbfa32e3b314047506dadf837d54e8e2a/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L946|https://github.com/hazelcast/hazelcast/blob/e3dd651a78e97c6702ce4260e6263d4818fb29b1/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L974]
[2]
[https://github.com/hazelcast/hazelcast/blob/e3dd651a78e97c6702ce4260e6263d4818fb29b1/hazelcast/src/main/java/com/hazelcast/config/AutoDetectionConfig.java#L28]
[3]https://github.com/hazelcast/hazelcast/blob/a3ae01dcbfa32e3b314047506dadf837d54e8e2a/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L938
> Nifi in standalone mode is not able to enable EmbeddedHazelcastCacheManager
>
>
> Key: NIFI-11859
> URL: https://issues.apache.org/jira/browse/NIFI-11859
> Project: Apache NiFi
> Issue Type: Bug
> Components: Configuration Management
>Affects Versions: 1.22.0
>Reporter: Jeetendra G Vasisht
>Priority: Blocker
> Attachments: embeddedHazelcastNifiControllerservice.PNG, nifi--app.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> EmbeddedHazelcastCacheManager Controller gets enabled in cluster mode with
> "All Nodes" clustering strategy, but having issue when tried to run in
> standalone mode with "None" clustering strategy. This is observed in
> Kubernetes Environment and this is coming as part of internal Nifi packaging
> and any external dependency or code related to Hazelcast is not being used.
> Controller gets stuck in Enabling state:
> !embeddedHazelcastNifiControllerservice.PNG|width=662,height=131!
> Respective Logs have been attached
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11859) Nifi in standalone mode is not able to enable EmbeddedHazelcastCacheManager
[
https://issues.apache.org/jira/browse/NIFI-11859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819071#comment-17819071
]
Bob Paulin commented on NIFI-11859:
---
Looks like Hazelcast will enable the Multicast Joinger[1] if autodetect is
enabled. And it is by default [2]. This causes Multicast to be enabled when
this is run locally
{code:java}
2024-02-20 19:14:41,547 INFO [Timer-Driven Process Thread-6]
com.hazelcast.instance.impl.Node [192.168.56.1]:5701 [nifi] [5.3.5] Using
Multicast discovery {code}
By disabling the auto detect this does not happen
[https://github.com/apache/nifi/pull/8440]
I get the following in the logs which I believe is expected.
{code:java}
2024-02-20 19:23:15,870 WARN [Timer-Driven Process Thread-2]
com.hazelcast.instance.impl.Node [192.168.56.1]:5701 [nifi] [5.3.5] No join
method is enabled! Starting standalone. {code}
This should also address the issue above since it appears to be hitting a
usecase where the DiscoveryJoiner is enabled. This should also be suppressed
by autodetect being disabled [3]. This appears to happen in both 1.x and 2.x
[1]
[https://github.com/hazelcast/hazelcast/blob/a3ae01dcbfa32e3b314047506dadf837d54e8e2a/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L946|https://github.com/hazelcast/hazelcast/blob/e3dd651a78e97c6702ce4260e6263d4818fb29b1/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L974]
[2]
[https://github.com/hazelcast/hazelcast/blob/e3dd651a78e97c6702ce4260e6263d4818fb29b1/hazelcast/src/main/java/com/hazelcast/config/AutoDetectionConfig.java#L28]
[3]https://github.com/hazelcast/hazelcast/blob/a3ae01dcbfa32e3b314047506dadf837d54e8e2a/hazelcast/src/main/java/com/hazelcast/instance/impl/Node.java#L938
> Nifi in standalone mode is not able to enable EmbeddedHazelcastCacheManager
>
>
> Key: NIFI-11859
> URL: https://issues.apache.org/jira/browse/NIFI-11859
> Project: Apache NiFi
> Issue Type: Bug
> Components: Configuration Management
>Affects Versions: 1.22.0
>Reporter: Jeetendra G Vasisht
>Priority: Blocker
> Attachments: embeddedHazelcastNifiControllerservice.PNG, nifi--app.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> EmbeddedHazelcastCacheManager Controller gets enabled in cluster mode with
> "All Nodes" clustering strategy, but having issue when tried to run in
> standalone mode with "None" clustering strategy. This is observed in
> Kubernetes Environment and this is coming as part of internal Nifi packaging
> and any external dependency or code related to Hazelcast is not being used.
> Controller gets stuck in Enabling state:
> !embeddedHazelcastNifiControllerservice.PNG|width=662,height=131!
> Respective Logs have been attached
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12681) Archetype should use NiFi version instead of version for nifi-standard-services-api-nar
[
https://issues.apache.org/jira/browse/NIFI-12681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811681#comment-17811681
]
Bob Paulin commented on NIFI-12681:
---
Thanks Joe. I get it. I have done it both ways myself as well. I generally
prefer not specifying when it comes from a BOM or a parent pom. Looking
forward to the next milestone.
> Archetype should use NiFi version instead of version for
> nifi-standard-services-api-nar
> ---
>
> Key: NIFI-12681
> URL: https://issues.apache.org/jira/browse/NIFI-12681
> Project: Apache NiFi
> Issue Type: Bug
> Components: Tools and Build
>Affects Versions: 2.0.0
>Reporter: Bob Paulin
>Priority: Minor
> Fix For: 2.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current nifi-processor-bundle-archetype sets the
> nifi-standard-services-api-nar to ${version} which matches the processor
> version instead of the version of NiFi being used.
>
> Suggest either removing the version entirely (it should inherit from the
> parent pom or set to ${nifiVersion} so it matches the version of NiFi being
> used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-12681) Archetype should use NiFi version instead of version for nifi-standard-services-api-nar
Bob Paulin created NIFI-12681:
-
Summary: Archetype should use NiFi version instead of version for
nifi-standard-services-api-nar
Key: NIFI-12681
URL: https://issues.apache.org/jira/browse/NIFI-12681
Project: Apache NiFi
Issue Type: Bug
Components: Tools and Build
Affects Versions: 2.0.0
Reporter: Bob Paulin
The current nifi-processor-bundle-archetype sets the
nifi-standard-services-api-nar to ${version} which matches the processor
version instead of the version of NiFi being used.
Suggest either removing the version entirely (it should inherit from the parent
pom or set to ${nifiVersion} so it matches the version of NiFi being used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
