[jira] [Commented] (MINIFI-218) Create GetGPS processor for acquiring GPS coordinates
[ https://issues.apache.org/jira/browse/MINIFI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875904#comment-15875904 ] Oleg Zhurakousky commented on MINIFI-218: - [~jskora] I must be missing something. I do see how such processors can be useful in pervasive devices (target area of Minify) that move around all the time, (as long as satellite is "visible"). Not sure though what use would one get out of them in the data center with known and never changing location and probably out of reach of satellites. > Create GetGPS processor for acquiring GPS coordinates > - > > Key: MINIFI-218 > URL: https://issues.apache.org/jira/browse/MINIFI-218 > Project: Apache NiFi MiNiFi > Issue Type: New Feature > Components: C++ >Reporter: Jeremy Dyer >Assignee: Jeremy Dyer > > GPSD is a popular framework for interacting with a multitude of GPS devices. > It drastically simplifies the interaction with vendor specific GPS devices by > providing a daemon service which communicates with the device, converts the > raw NMEA 0183 sentences into JSON objects, and then emits those JSON objects > over a socket for 0-N downstream devices to consume. > This feature would create a GetGPS processor that would listen to a running > instance of GPSD as one of those downstream consumers. The processor would > provide integration with the GPSD daemon to accept the JSON objects and > create new flowfiles for each of the JSON objects received. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (NIFI-2113) Upgrade NiFi's Storm Spout & Bolt to use Storm 1.0.0
[ https://issues.apache.org/jira/browse/NIFI-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky resolved NIFI-2113. Resolution: Fixed > Upgrade NiFi's Storm Spout & Bolt to use Storm 1.0.0 > > > Key: NIFI-2113 > URL: https://issues.apache.org/jira/browse/NIFI-2113 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Fix For: 1.0.0 > > > Storm 1.0.0 has been out for a little while now. For NiFi 1.0.0 we should > upgrade our dependency on Storm so we compile our spout and bolt against > Storm 1.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364347#comment-15364347 ] Oleg Zhurakousky commented on NIFI-2160: Thank you for you patience! > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363337#comment-15363337 ] Oleg Zhurakousky commented on NIFI-2160: [~devriesb] the above PR is for 0.x branch. Would be nice if you can apply it locally, build and validate. I'll have the one for 1.0 shortly as well > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363293#comment-15363293 ] Oleg Zhurakousky commented on NIFI-2160: So, simplified the logic where instead of sorting all the services it now uses recursive algorithm which ensures that IF a service has dependencies those are enabled before the actual service is enabled and if a particular service has already been enabled then all is good. It is much simpler to read and debug. Running full build now. > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363044#comment-15363044 ] Oleg Zhurakousky commented on NIFI-2160: Brandon Never mind, finally was able to reproduce and have a test to prove it. Stand by for PR > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[
https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362994#comment-15362994
]
Oleg Zhurakousky commented on NIFI-2160:
Thank you [~devriesb], so Mark and I both believe that the issue (as you
pointed out) may be with comparison logic. Basically on Java 8 it seem to be
fine and well the way it is now. However the fact that comparison logic is
based on only returning 1 or -1 means that the sorting is not completely
reliable and/or fully deterministic since it's lacking 0. So I am making the
following change in the comparator
https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L320,
but if you can pre-empt it and do it locally and build and lat us know that
would help greatly. Basically change is very simple:
Change
{code}
return s2.getRequiredControllerServices().contains(s1) ? -1 : 1;
{code}
to
{code}
return s2.getRequiredControllerServices().contains(s1) ? -1 :
(s1.getRequiredControllerServices().contains(s2) ? 1 : 0);
{code}
Meanwhile I'll try to reproduce it with Java 7, but please let me know if you
can do the above and it fixes the issue.
Thanks for all the input
> Enabled ControllerServices disabled on restart
> --
>
> Key: NIFI-2160
> URL: https://issues.apache.org/jira/browse/NIFI-2160
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Brandon DeVries
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.0.0, 0.7.0
>
>
> As a result of the fix for NIFI-2032, *previously enabled ControllerServices
> become disabled after a restart* if they are not referenced by another
> component. However, we use a custom domain specific langauge that can
> reference a controller service from a query defined as a custom processor's
> property. This means that we use a number of controller service that are
> only used in this way (i.e. are never directly referred to by another
> component). Upon restart, these are now disabled causing issues with our
> flows.
> I have not yet stepped through the new enableControllerServices() \[1\]
> method to figure out exactly where the issue is coming from, but I wanted to
> get the ticket out there and on the radar, as this breaks backwards
> compatibility on a feature we heavily rely on.
> \[1\]
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362952#comment-15362952 ] Oleg Zhurakousky commented on NIFI-2160: Also, what version of Java you're running? > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362861#comment-15362861 ] Oleg Zhurakousky commented on NIFI-2160: [~devriesb] really trying to get to the bottom of it, so need more help from you. Is there any way you can confirm that all services (parent and its dependencies) are passed in the list to the _enableControllerServices_ method? Basically I have a test at the moment that has 3 services A, B and C where A depends on B and C and B depends on C, so there are double dependency, yet regardless of what order I am passing them to the _enableControllerServices_ all starts successfully. > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362712#comment-15362712 ] Oleg Zhurakousky commented on NIFI-2160: Ok, I see, let me try to bootstrap a test, but please confirm the following when you get a chance. . . You have a CS that itself depends on other CS's, correct? > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362580#comment-15362580 ] Oleg Zhurakousky commented on NIFI-2160: [~devriesb] I just had a chat with [~markap14] and we are both suspecting that your custom logic (e.g., customValidate) may be checking for service being ENABLED and based on the recent changes it actually have to check on ENABLED or ENABLING. Could you please verify? > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362533#comment-15362533 ] Oleg Zhurakousky commented on NIFI-2160: [~devriesb] For a second there I thought I've noticed the issue, but I can't seem to reproduce it no mater what I do. I've tried with just a ControllerService and with ControllerService connected to the Processor, the result is that ENABLED ControllerService is still ENABLED after restart. Please advice. Meanwhile I'll keep on digging. > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2164) ConsumeJMS should allow user to configure trade-off between 'best effort' and 'guaranteed receipt' of data
[ https://issues.apache.org/jira/browse/NIFI-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-2164: -- Assignee: Oleg Zhurakousky > ConsumeJMS should allow user to configure trade-off between 'best effort' and > 'guaranteed receipt' of data > -- > > Key: NIFI-2164 > URL: https://issues.apache.org/jira/browse/NIFI-2164 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Mark Payne >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > Currently the ConsumeJMS Processor uses auto-acknowledge acknowledgement. > This is beneficial for many use cases but could result in data loss if NiFi > is shut down. We should expose a 'Delivery Guarantee' property that allows > the user to choose between 'Best Effort', which will provide better > performance or 'Guaranteed Receipt', which will guarantee that data has been > committed to NiFi's Content & FlowFile Repositories before acknowledging the > message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2160) Enabled ControllerServices disabled on restart
[ https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-2160: -- Assignee: Oleg Zhurakousky > Enabled ControllerServices disabled on restart > -- > > Key: NIFI-2160 > URL: https://issues.apache.org/jira/browse/NIFI-2160 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Brandon DeVries >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 0.7.0 > > > As a result of the fix for NIFI-2032, *previously enabled ControllerServices > become disabled after a restart* if they are not referenced by another > component. However, we use a custom domain specific langauge that can > reference a controller service from a query defined as a custom processor's > property. This means that we use a number of controller service that are > only used in this way (i.e. are never directly referred to by another > component). Upon restart, these are now disabled causing issues with our > flows. > I have not yet stepped through the new enableControllerServices() \[1\] > method to figure out exactly where the issue is coming from, but I wanted to > get the ticket out there and on the radar, as this breaks backwards > compatibility on a feature we heavily rely on. > \[1\] > https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2160) Enabled ControllerServices disabled on restart
[
https://issues.apache.org/jira/browse/NIFI-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358920#comment-15358920
]
Oleg Zhurakousky commented on NIFI-2160:
Brandon
Correct me if I am wrong, but based on your explanation you're using some
custom code (". . .we use a custom domain specific langauge that can reference
a controller service. . .") to reference the CS. That means NiFi is not aware
of this relationship(s).
I do understand that this is a problem within your current approach, but if the
above is correct I wonder if this is really a bug in NiFi (let alone
"Critical"). IMHO, NiFi has a very specific way of defining the relationships
between components and if any relationships exist outside of NiFi core
relationship model, then don't you think it would be the responsibility of your
custom DSL to enable the CS if it is disabled?
That said, I think the real issue is simply with the fact that CS (regardless
of it's relationship to anything) was in ENABLED state when NiFi was shut down
and is DISABLED upon restart of NiFi. That is indeed a bug. Do you agree? If
so, I'll be more then glad to make it a priority, otherwise let's make sure
we're are addressing the real issue (whatever that may be).
> Enabled ControllerServices disabled on restart
> --
>
> Key: NIFI-2160
> URL: https://issues.apache.org/jira/browse/NIFI-2160
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Brandon DeVries
>Priority: Critical
> Fix For: 0.7.0
>
>
> As a result of the fix for NIFI-2032, previously enabled ControllerServices
> become disabled after a restart if they are not referenced by another
> component. However, we use a custom domain specific langauge that can
> reference a controller service from a query defined as a custom processor's
> property. This means that we use a number of controller service that are
> only used in this way (i.e. are never directly referred to by another
> component). Upon restart, these are now disabled causing issues with our
> flows.
> I have not yet stepped through the new enableControllerServices() \[1\]
> method to figure out exactly where the issue is coming from, but I wanted to
> get the ticket out there and on the radar, as this breaks backwards
> compatibility on a feature we heavily rely on.
> \[1\]
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java#L301-336
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-2067) Fix MonitorMemory unit tests
[ https://issues.apache.org/jira/browse/NIFI-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2067: --- Fix Version/s: 0.7.0 1.0.0 > Fix MonitorMemory unit tests > > > Key: NIFI-2067 > URL: https://issues.apache.org/jira/browse/NIFI-2067 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Oleg Zhurakousky >Priority: Minor > Fix For: 1.0.0, 0.7.0 > > > I've seen failures in the MonitorMemory unit tests in tickets that are > completely unrelated to MonitorMemory. For example, these PutTCP builds: > https://travis-ci.org/apache/nifi/builds/139104774 > The MonitorMemory unit tests should be changed to be more consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-2066) Fix concurrency in SNMP processor unit tests
[ https://issues.apache.org/jira/browse/NIFI-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky resolved NIFI-2066. Resolution: Fixed > Fix concurrency in SNMP processor unit tests > > > Key: NIFI-2066 > URL: https://issues.apache.org/jira/browse/NIFI-2066 > Project: Apache NiFi > Issue Type: Test > Components: Extensions >Affects Versions: 0.6.1 >Reporter: Pierre Villard >Assignee: Pierre Villard > Fix For: 1.0.0, 0.7.0 > > > Travis build is currently failing because of unit testing in SNMP processors. > It seems to be explained by concurrent executions of the unit tests and the > unavailability of ports already in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2066) Fix concurrency in SNMP processor unit tests
[ https://issues.apache.org/jira/browse/NIFI-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2066: --- Fix Version/s: 0.7.0 1.0.0 > Fix concurrency in SNMP processor unit tests > > > Key: NIFI-2066 > URL: https://issues.apache.org/jira/browse/NIFI-2066 > Project: Apache NiFi > Issue Type: Test > Components: Extensions >Affects Versions: 0.6.1 >Reporter: Pierre Villard > Fix For: 1.0.0, 0.7.0 > > > Travis build is currently failing because of unit testing in SNMP processors. > It seems to be explained by concurrent executions of the unit tests and the > unavailability of ports already in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2066) Fix concurrency in SNMP processor unit tests
[ https://issues.apache.org/jira/browse/NIFI-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2066: --- Assignee: Pierre Villard > Fix concurrency in SNMP processor unit tests > > > Key: NIFI-2066 > URL: https://issues.apache.org/jira/browse/NIFI-2066 > Project: Apache NiFi > Issue Type: Test > Components: Extensions >Affects Versions: 0.6.1 >Reporter: Pierre Villard >Assignee: Pierre Villard > Fix For: 1.0.0, 0.7.0 > > > Travis build is currently failing because of unit testing in SNMP processors. > It seems to be explained by concurrent executions of the unit tests and the > unavailability of ports already in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2066) Fix concurrency in SNMP processor unit tests
[ https://issues.apache.org/jira/browse/NIFI-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2066: --- Affects Version/s: (was: 0.7.0) (was: 1.0.0) 0.6.1 > Fix concurrency in SNMP processor unit tests > > > Key: NIFI-2066 > URL: https://issues.apache.org/jira/browse/NIFI-2066 > Project: Apache NiFi > Issue Type: Test > Components: Extensions >Affects Versions: 0.6.1 >Reporter: Pierre Villard > Fix For: 1.0.0, 0.7.0 > > > Travis build is currently failing because of unit testing in SNMP processors. > It seems to be explained by concurrent executions of the unit tests and the > unavailability of ports already in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2067) Fix MonitorMemory unit tests
[ https://issues.apache.org/jira/browse/NIFI-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-2067: -- Assignee: Oleg Zhurakousky > Fix MonitorMemory unit tests > > > Key: NIFI-2067 > URL: https://issues.apache.org/jira/browse/NIFI-2067 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Oleg Zhurakousky >Priority: Minor > > I've seen failures in the MonitorMemory unit tests in tickets that are > completely unrelated to MonitorMemory. For example, these PutTCP builds: > https://travis-ci.org/apache/nifi/builds/139104774 > The MonitorMemory unit tests should be changed to be more consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2066) Fix concurrency in SNMP processor unit tests
[ https://issues.apache.org/jira/browse/NIFI-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15341935#comment-15341935 ] Oleg Zhurakousky commented on NIFI-2066: [~pvillard] Are you binding to specific port of random? For example here is what we do for embedded kafka server https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/test/java/org/apache/nifi/processors/kafka/test/EmbeddedKafka.java#L210 > Fix concurrency in SNMP processor unit tests > > > Key: NIFI-2066 > URL: https://issues.apache.org/jira/browse/NIFI-2066 > Project: Apache NiFi > Issue Type: Test > Components: Extensions >Affects Versions: 1.0.0, 0.7.0 >Reporter: Pierre Villard > > Travis build is currently failing because of unit testing in SNMP processors. > It seems to be explained by concurrent executions of the unit tests and the > unavailability of ports already in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1815) Tesseract OCR Processor
[
https://issues.apache.org/jira/browse/NIFI-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15339892#comment-15339892
]
Oleg Zhurakousky commented on NIFI-1815:
Guys
We may need to rethink this a bit
While current PR looks good and processor performs what it supposed to do,
tess4j pulls several libraries under licenses that are not compatible with ASF
policies. Below are the libraries in question and their licenses:
{code}
itext - GNU Affero General Public License v3
ghost4j - GNU LESSER GENERAL PUBLIC LICENSE
jai* - BSD 3-clause License
rococoa - LGPL 3
{code}
Possible solutions could be to employ the same model that is used by JMS and
Spring components of NIFi where the end user is responsible for pointing to the
libraries as part of the configuration, so the distribution does not require
them.
[~jeremy.dyer] ping me and we can discuss how to accomplish this. As I said,
we're doing it already in both JMS and Spring components, so not the most
complex issue.
> Tesseract OCR Processor
> ---
>
> Key: NIFI-1815
> URL: https://issues.apache.org/jira/browse/NIFI-1815
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Jeremy Dyer
>Assignee: Jeremy Dyer
> Attachments: 0006-changes-to-the-OCR-processor.patch,
> nifi_1815_1.x_patch.zip
>
>
> This ticket is a follow-up to NIFI-1718 minus the use of the Tika library
> Expose OCR capabilities through a new processor which uses the Tesseract
> library. Use of this processor would require that Tesseract be installed on
> the NiFi host. Since the processor will have a system dependency care must be
> taken to ensure that the overall NiFi cluster continues to function properly
> in the absence of the Tesseract system dependency even though the OCR
> processor itself will be unable to perform its duties. In the event that the
> system dependencies are not detected the processor should display a
> validation warning rather than failing or preventing the NiFi instance from
> booting properly.
> Properties expose to configure Tesseract
> tesseractPath - Path to tesseract installation folder, if not on system path.
> language - Language ID (e.g. "eng"); language dictionary to be used.
> pageSegMode - Tesseract page segmentation mode, defaults to 1.
> minFileSizeToOcr - Minimum file size to submit file to OCR, defaults to 0.
> maxFileSizeToOcr - Maximum file size to submit file to OCR, defaults to
> Integer.MAX_VALUE.
> timeout - Maximum time (in seconds) to wait for the OCR process termination;
> defaults to 120.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-2032) Processors could be started before the Controller Services that they depend on
[ https://issues.apache.org/jira/browse/NIFI-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2032: --- Fix Version/s: 0.7.0 > Processors could be started before the Controller Services that they depend on > -- > > Key: NIFI-2032 > URL: https://issues.apache.org/jira/browse/NIFI-2032 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > in the StandardControllerServiceProvider, we enable a Collection of > Controller Services but do so in the background with a limited number of > threads. We need to ensure that all Controller Services have at least become > ENABLING before returning from this method. Otherwise, Processors that depend > on them could attempt to start. If this happens, the Processor will be > invalid because it references a Disabled Controller Service. As a result, the > Processor will not start. In a clustered environment, we will end up with > inconsistent run states across the nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2032) Processors could be started before the Controller Services that they depend on
[ https://issues.apache.org/jira/browse/NIFI-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2032: --- Fix Version/s: (was: 0.7.0) > Processors could be started before the Controller Services that they depend on > -- > > Key: NIFI-2032 > URL: https://issues.apache.org/jira/browse/NIFI-2032 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0 > > > in the StandardControllerServiceProvider, we enable a Collection of > Controller Services but do so in the background with a limited number of > threads. We need to ensure that all Controller Services have at least become > ENABLING before returning from this method. Otherwise, Processors that depend > on them could attempt to start. If this happens, the Processor will be > invalid because it references a Disabled Controller Service. As a result, the > Processor will not start. In a clustered environment, we will end up with > inconsistent run states across the nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (NIFI-1779) SNMP
[ https://issues.apache.org/jira/browse/NIFI-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reopened NIFI-1779: > SNMP > - > > Key: NIFI-1779 > URL: https://issues.apache.org/jira/browse/NIFI-1779 > Project: Apache NiFi > Issue Type: Wish > Components: Core Framework >Affects Versions: 0.6.0 > Environment: n/a >Reporter: Manoj Kalikodanveetil > > Hi, > In one of NiFi 0.6.0 release notes it was mentioned that SNMP input handler > being added. But I don't see that in 0.6. Is that backed out? > Or is the plan to make use of Camel? > thanks > Manoj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-1779) SNMP
[ https://issues.apache.org/jira/browse/NIFI-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky resolved NIFI-1779. Resolution: Duplicate > SNMP > - > > Key: NIFI-1779 > URL: https://issues.apache.org/jira/browse/NIFI-1779 > Project: Apache NiFi > Issue Type: Wish > Components: Core Framework >Affects Versions: 0.6.0 > Environment: n/a >Reporter: Manoj Kalikodanveetil > > Hi, > In one of NiFi 0.6.0 release notes it was mentioned that SNMP input handler > being added. But I don't see that in 0.6. Is that backed out? > Or is the plan to make use of Camel? > thanks > Manoj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1537) Add SNMP processors
[ https://issues.apache.org/jira/browse/NIFI-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1537: --- Fix Version/s: 1.0.0 > Add SNMP processors > --- > > Key: NIFI-1537 > URL: https://issues.apache.org/jira/browse/NIFI-1537 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 0.5.0 >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Minor > Labels: snmp > Fix For: 1.0.0, 0.7.0 > > > Add SNMP processors: > - GetSNMP to allow "get"/"walk" > - SetSNMP to allow "set" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-1955) Deprecate IntegerHolder, LongHolder, BooleanHolder
[ https://issues.apache.org/jira/browse/NIFI-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky resolved NIFI-1955. Resolution: Fixed > Deprecate IntegerHolder, LongHolder, BooleanHolder > -- > > Key: NIFI-1955 > URL: https://issues.apache.org/jira/browse/NIFI-1955 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Reporter: Michael Moser >Priority: Trivial > Fix For: 1.0.0, 0.7.0 > > > For similar reasons that ObjectHolder was deprecated in NIFI-1771, also > deprecate: _org.apache.nifi.util.IntegerHolder_, > _org.apache.nifi.util.LongHolder_, _org.apache.nifi.util.BooleanHolder_ > Use of AtomicInteger, AtomicLong, AtomicBoolean is preferred. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1955) Deprecate IntegerHolder, LongHolder, BooleanHolder
[ https://issues.apache.org/jira/browse/NIFI-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1955: --- Fix Version/s: 0.7.0 1.0.0 > Deprecate IntegerHolder, LongHolder, BooleanHolder > -- > > Key: NIFI-1955 > URL: https://issues.apache.org/jira/browse/NIFI-1955 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Reporter: Michael Moser >Priority: Trivial > Fix For: 1.0.0, 0.7.0 > > > For similar reasons that ObjectHolder was deprecated in NIFI-1771, also > deprecate: _org.apache.nifi.util.IntegerHolder_, > _org.apache.nifi.util.LongHolder_, _org.apache.nifi.util.BooleanHolder_ > Use of AtomicInteger, AtomicLong, AtomicBoolean is preferred. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-1549) Bug in JMSConsumer makes it hard to debug failure in processing JMS messages.
[
https://issues.apache.org/jira/browse/NIFI-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky resolved NIFI-1549.
Resolution: Fixed
> Bug in JMSConsumer makes it hard to debug failure in processing JMS messages.
> -
>
> Key: NIFI-1549
> URL: https://issues.apache.org/jira/browse/NIFI-1549
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.5.0
>Reporter: Christopher McDermott
>Priority: Trivial
> Fix For: 1.0.0, 0.7.0
>
>
> Minor bug in JMSConsumer makes it hard to debug failure in processing JMS
> messages. Fix is trivial.
> {code:java}
> diff --git
> a/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
>
> b/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
> index ea70d52..c820174 100644
> ---
> a/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
> +++
> b/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
> @@ -197,7 +197,7 @@ public abstract class JmsConsumer extends
> AbstractProcessor {
> final byte[] messageBody =
> JmsFactory.createByteArray(message);
> out.write(messageBody);
> } catch (final JMSException e) {
> -throw new ProcessException("Failed to receive
> JMS Message due to {}", e);
> +throw new ProcessException("Failed to receive
> JMS Message due to " + e.getMessage(), e);
> }
> }
> });
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-1549) Bug in JMSConsumer makes it hard to debug failure in processing JMS messages.
[
https://issues.apache.org/jira/browse/NIFI-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky updated NIFI-1549:
---
Fix Version/s: 0.7.0
1.0.0
> Bug in JMSConsumer makes it hard to debug failure in processing JMS messages.
> -
>
> Key: NIFI-1549
> URL: https://issues.apache.org/jira/browse/NIFI-1549
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 0.5.0
>Reporter: Christopher McDermott
>Priority: Trivial
> Fix For: 1.0.0, 0.7.0
>
>
> Minor bug in JMSConsumer makes it hard to debug failure in processing JMS
> messages. Fix is trivial.
> {code:java}
> diff --git
> a/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
>
> b/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
> index ea70d52..c820174 100644
> ---
> a/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
> +++
> b/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/JmsConsumer.java
> @@ -197,7 +197,7 @@ public abstract class JmsConsumer extends
> AbstractProcessor {
> final byte[] messageBody =
> JmsFactory.createByteArray(message);
> out.write(messageBody);
> } catch (final JMSException e) {
> -throw new ProcessException("Failed to receive
> JMS Message due to {}", e);
> +throw new ProcessException("Failed to receive
> JMS Message due to " + e.getMessage(), e);
> }
> }
> });
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-1690) Misconfigured MonitorMemory ReportingTask can not be stopped
[ https://issues.apache.org/jira/browse/NIFI-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1690: --- Fix Version/s: 0.7.0 > Misconfigured MonitorMemory ReportingTask can not be stopped > > > Key: NIFI-1690 > URL: https://issues.apache.org/jira/browse/NIFI-1690 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.5.1 >Reporter: Matthew Clarke >Assignee: Oleg Zhurakousky > Fix For: 1.0.0, 0.7.0 > > > The monitor memory reporting tasks allows the user to entire any value > they want for the JVM memory pool. If the supplied value is not valid (NiFi > can not find a memory pool with the supplied value), the reporting tasks > appears to get stuck in the @onDemand state. At this point the task can not > be stopped, edited, or deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1730) org/apache/nifi/util/ReflectionUtils.java (and possibly other classes) exist in two different modules under the same FQN
[
https://issues.apache.org/jira/browse/NIFI-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333757#comment-15333757
]
Oleg Zhurakousky commented on NIFI-1730:
Just to continue to document. . . .
This is now starting to hurt as two classes began to diverge significantly. For
example:
{code}
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(Ljava/lang/Class;Ljava/lang/Class;Ljava/lang/Object;[Ljava/lang/Object;)V
{code}
has been removed from
https://github.com/apache/nifi/blob/master/nifi-mock/src/main/java/org/apache/nifi/util/ReflectionUtils.java
which causes breaking changes in existing work (e.g., NiFi-1690)
> org/apache/nifi/util/ReflectionUtils.java (and possibly other classes) exist
> in two different modules under the same FQN
>
>
> Key: NIFI-1730
> URL: https://issues.apache.org/jira/browse/NIFI-1730
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> _org/apache/nifi/util/ReflectionUtils.java_ specifically exists in _framework
> core_ and _mock_ under the same FQN (see below)
> *
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/util/ReflectionUtils.java
> *
> https://github.com/apache/nifi/blob/master/nifi-mock/src/main/java/org/apache/nifi/util/ReflectionUtils.java
> This means that if the two versions are not identical one can start seeing
> something along the lines of this:
> {code}
> java.lang.NoSuchMethodError:
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(Ljava/lang/Class;Ljava/lang/Class;Ljava/lang/Object;[Ljava/lang/Object;)V
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-1690) Misconfigured MonitorMemory ReportingTask can not be stopped
[ https://issues.apache.org/jira/browse/NIFI-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1690: --- Fix Version/s: (was: 0.7.0) > Misconfigured MonitorMemory ReportingTask can not be stopped > > > Key: NIFI-1690 > URL: https://issues.apache.org/jira/browse/NIFI-1690 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.5.1 >Reporter: Matthew Clarke >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > The monitor memory reporting tasks allows the user to entire any value > they want for the JVM memory pool. If the supplied value is not valid (NiFi > can not find a memory pool with the supplied value), the reporting tasks > appears to get stuck in the @onDemand state. At this point the task can not > be stopped, edited, or deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2034) NiFi is always loading a specific version of httpcore to classpath
[ https://issues.apache.org/jira/browse/NIFI-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333704#comment-15333704 ] Oleg Zhurakousky commented on NIFI-2034: Would you be able to share what's in the classpath (POM, Gradle etc) of your custom processor? > NiFi is always loading a specific version of httpcore to classpath > -- > > Key: NIFI-2034 > URL: https://issues.apache.org/jira/browse/NIFI-2034 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.5.1, 0.6.1 >Reporter: asanka sanjaya > > We have written a custom nifi processor to connect to microsoft exchange > server and get emails. It runs perfectly as a standalone application. But > nifi always loads httpcore-4.4.1.jar and httpclient-4.4.1.jar to classpath > even though the nar file contains httpcore-4.4.4.jar and httpclient-4.5.2.jar. > Because of that, it throws this error. > 016-06-15 18:57:17,086 WARN [Timer-Driven Process Thread-4] > o.a.n.c.t.ContinuallyRunProcessorTask Administratively Yielding > NiFiJournalJob[id=52616329-d64c-4e14-bcb1-4c799891682a] due to uncaught > Exception: java.lang.NoSuchFieldError: INSTANCE > 2016-06-15 18:57:17,091 WARN [Timer-Driven Process Thread-4] > o.a.n.c.t.ContinuallyRunProcessorTask > java.lang.NoSuchFieldError: INSTANCE > at > org.apache.http.impl.io.DefaultHttpRequestWriterFactory.(DefaultHttpRequestWriterFactory.java:52) > ~[httpcore-4.4.1.jar:4.4.1] > at > org.apache.http.impl.io.DefaultHttpRequestWriterFactory.(DefaultHttpRequestWriterFactory.java:56) > ~[httpcore-4.4.1.jar:4.4.1] > at > org.apache.http.impl.io.DefaultHttpRequestWriterFactory.(DefaultHttpRequestWriterFactory.java:46) > ~[httpcore-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:82) > ~[httpclient-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:95) > ~[httpclient-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:104) > ~[httpclient-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:62) > ~[httpclient-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.BasicHttpClientConnectionManager.(BasicHttpClientConnectionManager.java:142) > ~[httpclient-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.BasicHttpClientConnectionManager.(BasicHttpClientConnectionManager.java:128) > ~[httpclient-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.BasicHttpClientConnectionManager.(BasicHttpClientConnectionManager.java:157) > ~[httpclient-4.4.1.jar:4.4.1] > at > microsoft.exchange.webservices.data.core.ExchangeServiceBase.initializeHttpClient(ExchangeServiceBase.java:199) > ~[na:na] > at > microsoft.exchange.webservices.data.core.ExchangeServiceBase.(ExchangeServiceBase.java:174) > ~[na:na] > at > microsoft.exchange.webservices.data.core.ExchangeServiceBase.(ExchangeServiceBase.java:179) > ~[na:na] > at > microsoft.exchange.webservices.data.core.ExchangeService.(ExchangeService.java:3729) > ~[na:na] > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2032) Processors could be started before the Controller Services that they depend on
[ https://issues.apache.org/jira/browse/NIFI-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-2032: -- Assignee: Oleg Zhurakousky > Processors could be started before the Controller Services that they depend on > -- > > Key: NIFI-2032 > URL: https://issues.apache.org/jira/browse/NIFI-2032 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Mark Payne >Assignee: Oleg Zhurakousky > > in the StandardControllerServiceProvider, we enable a Collection of > Controller Services but do so in the background with a limited number of > threads. We need to ensure that all Controller Services have at least become > ENABLING before returning from this method. Otherwise, Processors that depend > on them could attempt to start. If this happens, the Processor will be > invalid because it references a Disabled Controller Service. As a result, the > Processor will not start. In a clustered environment, we will end up with > inconsistent run states across the nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2015) Corrupted flow file leads to a wedged flow
[ https://issues.apache.org/jira/browse/NIFI-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2015: --- Fix Version/s: (was: 0.7.0) (was: 1.0.0) > Corrupted flow file leads to a wedged flow > -- > > Key: NIFI-2015 > URL: https://issues.apache.org/jira/browse/NIFI-2015 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Christopher McDermott >Assignee: Oleg Zhurakousky >Priority: Critical > > Encountered the following error. Once encountered the processor in question > cannot make any progress. The incoming connection cannot be emptied or even > listed. Note this issue is not to address the corrupted flow file but rather > the handling of the corrupted file. > 2016-06-13 17:33:30,275 ERROR [Timer-Driven Process Thread-4] > o.a.n.p.attributes.UpdateAttribute > java.lang.IllegalStateException: Cannot create Provenance Event Record > because FlowFile UUID is not set > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.assertSet(StandardProvenanceEventRecord.java:700) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:721) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:412) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.updateProvenanceRepo(StandardProcessSession.java:634) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:295) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:283) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2015) Corrupted flow file leads to a wedged flow
[ https://issues.apache.org/jira/browse/NIFI-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330225#comment-15330225 ] Oleg Zhurakousky commented on NIFI-2015: Chris, here is what I would suggest. We can keep this issue open, yet un-version it and wait to see if it ever happens again or you or anyone else can come up with steps to reproduce it in the controlled environment. I know that is not the best answer, but I personally can't even wrap my head around as to what has to be fixed. Assertion is there, it throws the exception and based on what I've tested NiFi reacts appropriately to the exception and continues. I am not saying there is no bug, but I am saying now that it is very reasonable to suspect that there was something else that triggered NiFi "wedging" while you also saw the corrupt FlowFile. Do you agree? > Corrupted flow file leads to a wedged flow > -- > > Key: NIFI-2015 > URL: https://issues.apache.org/jira/browse/NIFI-2015 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Christopher McDermott >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Encountered the following error. Once encountered the processor in question > cannot make any progress. The incoming connection cannot be emptied or even > listed. Note this issue is not to address the corrupted flow file but rather > the handling of the corrupted file. > 2016-06-13 17:33:30,275 ERROR [Timer-Driven Process Thread-4] > o.a.n.p.attributes.UpdateAttribute > java.lang.IllegalStateException: Cannot create Provenance Event Record > because FlowFile UUID is not set > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.assertSet(StandardProvenanceEventRecord.java:700) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:721) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:412) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.updateProvenanceRepo(StandardProcessSession.java:634) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:295) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:283) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2015) Corrupted flow file leads to a wedged flow
[ https://issues.apache.org/jira/browse/NIFI-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330051#comment-15330051 ] Oleg Zhurakousky commented on NIFI-2015: [~markap14] no it is not the same as NIFI-2006 ;) That one already has a PR As for the other things. Chris explained it in the email that somehow he (deliberately) corrupted a FlowFile resulting in no-uuid and even though you are saying it should not be possible, my concern was that according to Chris the NiFi became unavailable. Now I've easily reproduced such corruption by temporarily introducing "questionable code" and I did see the same stack trace as Chris is reporting. What I could not observe is "wedged" NiFi. It was running fine and I was able to perform all kinds of actions (see above). So my *only* remaining concern is if there is a condition related to this issue that renders NiFi unavailable. Otherwise I am perfectly fine with recommending "No Fix". > Corrupted flow file leads to a wedged flow > -- > > Key: NIFI-2015 > URL: https://issues.apache.org/jira/browse/NIFI-2015 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Christopher McDermott >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Encountered the following error. Once encountered the processor in question > cannot make any progress. The incoming connection cannot be emptied or even > listed. Note this issue is not to address the corrupted flow file but rather > the handling of the corrupted file. > 2016-06-13 17:33:30,275 ERROR [Timer-Driven Process Thread-4] > o.a.n.p.attributes.UpdateAttribute > java.lang.IllegalStateException: Cannot create Provenance Event Record > because FlowFile UUID is not set > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.assertSet(StandardProvenanceEventRecord.java:700) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:721) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:412) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.updateProvenanceRepo(StandardProcessSession.java:634) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:295) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:283) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2015) Corrupted flow file leads to a wedged flow
[ https://issues.apache.org/jira/browse/NIFI-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329981#comment-15329981 ] Oleg Zhurakousky commented on NIFI-2015: Chris I may need some help from you. I was able to modify some code to reproduce the error you are seeing (stack trace). However, what I can't reproduce is the "wedged" flow. I was able to successfully start/stop processors, list/delete elements in the queue and all in all the flow and the NiFi was responsive at all time. So looking for some help/pointers in reproducing it > Corrupted flow file leads to a wedged flow > -- > > Key: NIFI-2015 > URL: https://issues.apache.org/jira/browse/NIFI-2015 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Christopher McDermott >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Encountered the following error. Once encountered the processor in question > cannot make any progress. The incoming connection cannot be emptied or even > listed. Note this issue is not to address the corrupted flow file but rather > the handling of the corrupted file. > 2016-06-13 17:33:30,275 ERROR [Timer-Driven Process Thread-4] > o.a.n.p.attributes.UpdateAttribute > java.lang.IllegalStateException: Cannot create Provenance Event Record > because FlowFile UUID is not set > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.assertSet(StandardProvenanceEventRecord.java:700) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:721) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:412) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.updateProvenanceRepo(StandardProcessSession.java:634) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:295) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:283) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2006) Null attribute values causing NPEs in provenance repo
[
https://issues.apache.org/jira/browse/NIFI-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329668#comment-15329668
]
Oleg Zhurakousky commented on NIFI-2006:
Yeah, somehow I've mixed two things in my head. I just can't remember why I was
looking a the same code snippet as in Brandon's JIRA while I was investigating
yours. Anyway, I'll re-open NIFI-2015
> Null attribute values causing NPEs in provenance repo
> -
>
> Key: NIFI-2006
> URL: https://issues.apache.org/jira/browse/NIFI-2006
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Brandon DeVries
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.0.0, 0.7.0
>
>
> A null attribute value (as you would see for a removed attribute) causes the
> provenance repo to thrown an NPE here:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1789
> (as "entry.getValue()" is null...)
> suggested fix is to change:
> {code}
> if (entry.getValue().length() > maxAttributeChars) {
> {code}
> to:
> {code}
> if (entry.getValue() != null && entry.getValue().length() >
> maxAttributeChars) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2006) Null attribute values causing NPEs in provenance repo
[
https://issues.apache.org/jira/browse/NIFI-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329659#comment-15329659
]
Oleg Zhurakousky commented on NIFI-2006:
I am now coming to this realization myself ;), stay tuned
> Null attribute values causing NPEs in provenance repo
> -
>
> Key: NIFI-2006
> URL: https://issues.apache.org/jira/browse/NIFI-2006
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Brandon DeVries
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.0.0, 0.7.0
>
>
> A null attribute value (as you would see for a removed attribute) causes the
> provenance repo to thrown an NPE here:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1789
> (as "entry.getValue()" is null...)
> suggested fix is to change:
> {code}
> if (entry.getValue().length() > maxAttributeChars) {
> {code}
> to:
> {code}
> if (entry.getValue() != null && entry.getValue().length() >
> maxAttributeChars) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NIFI-2015) Corrupted flow file leads to a wedged flow
[ https://issues.apache.org/jira/browse/NIFI-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky resolved NIFI-2015. Resolution: Duplicate [~ch...@mcdermott.net] I just noticed that this issue was already reported by [~devriesb] yesterday, so am marking this as duplicate. In any event, thank you for discovering and reporting it! > Corrupted flow file leads to a wedged flow > -- > > Key: NIFI-2015 > URL: https://issues.apache.org/jira/browse/NIFI-2015 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Christopher McDermott >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Encountered the following error. Once encountered the processor in question > cannot make any progress. The incoming connection cannot be emptied or even > listed. Note this issue is not to address the corrupted flow file but rather > the handling of the corrupted file. > 2016-06-13 17:33:30,275 ERROR [Timer-Driven Process Thread-4] > o.a.n.p.attributes.UpdateAttribute > java.lang.IllegalStateException: Cannot create Provenance Event Record > because FlowFile UUID is not set > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.assertSet(StandardProvenanceEventRecord.java:700) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:721) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:412) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.updateProvenanceRepo(StandardProcessSession.java:634) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:295) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:283) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2006) Null attribute values causing NPEs in provenance repo
[
https://issues.apache.org/jira/browse/NIFI-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky reassigned NIFI-2006:
--
Assignee: Oleg Zhurakousky
> Null attribute values causing NPEs in provenance repo
> -
>
> Key: NIFI-2006
> URL: https://issues.apache.org/jira/browse/NIFI-2006
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Brandon DeVries
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.0.0, 0.7.0
>
>
> A null attribute value (as you would see for a removed attribute) causes the
> provenance repo to thrown an NPE here:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1789
> (as "entry.getValue()" is null...)
> suggested fix is to change:
> {code}
> if (entry.getValue().length() > maxAttributeChars) {
> {code}
> to:
> {code}
> if (entry.getValue() != null && entry.getValue().length() >
> maxAttributeChars) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-2006) Null attribute values causing NPEs in provenance repo
[
https://issues.apache.org/jira/browse/NIFI-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329602#comment-15329602
]
Oleg Zhurakousky commented on NIFI-2006:
The issue was originally reported by a community member
([~ch...@mcdermott.net]) on the dev list yesterday with me suggesting to raise
a JIRA which he did as NIFI-2015 albeit a bit late. So I am addressing it now
and will mark NIFI-2015 as duplicate.
> Null attribute values causing NPEs in provenance repo
> -
>
> Key: NIFI-2006
> URL: https://issues.apache.org/jira/browse/NIFI-2006
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Brandon DeVries
>Priority: Critical
> Fix For: 1.0.0, 0.7.0
>
>
> A null attribute value (as you would see for a removed attribute) causes the
> provenance repo to thrown an NPE here:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1789
> (as "entry.getValue()" is null...)
> suggested fix is to change:
> {code}
> if (entry.getValue().length() > maxAttributeChars) {
> {code}
> to:
> {code}
> if (entry.getValue() != null && entry.getValue().length() >
> maxAttributeChars) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (NIFI-2015) Corrupted flow file leads to a wedged flow
[ https://issues.apache.org/jira/browse/NIFI-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-2015: -- Assignee: Oleg Zhurakousky > Corrupted flow file leads to a wedged flow > -- > > Key: NIFI-2015 > URL: https://issues.apache.org/jira/browse/NIFI-2015 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Christopher McDermott >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Encountered the following error. Once encountered the processor in question > cannot make any progress. The incoming connection cannot be emptied or even > listed. Note this issue is not to address the corrupted flow file but rather > the handling of the corrupted file. > 2016-06-13 17:33:30,275 ERROR [Timer-Driven Process Thread-4] > o.a.n.p.attributes.UpdateAttribute > java.lang.IllegalStateException: Cannot create Provenance Event Record > because FlowFile UUID is not set > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.assertSet(StandardProvenanceEventRecord.java:700) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:721) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:412) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.updateProvenanceRepo(StandardProcessSession.java:634) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:295) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:283) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2015) Corrupted flow file leads to a wedged flow
[ https://issues.apache.org/jira/browse/NIFI-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2015: --- Fix Version/s: 0.7.0 1.0.0 > Corrupted flow file leads to a wedged flow > -- > > Key: NIFI-2015 > URL: https://issues.apache.org/jira/browse/NIFI-2015 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Christopher McDermott >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Encountered the following error. Once encountered the processor in question > cannot make any progress. The incoming connection cannot be emptied or even > listed. Note this issue is not to address the corrupted flow file but rather > the handling of the corrupted file. > 2016-06-13 17:33:30,275 ERROR [Timer-Driven Process Thread-4] > o.a.n.p.attributes.UpdateAttribute > java.lang.IllegalStateException: Cannot create Provenance Event Record > because FlowFile UUID is not set > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.assertSet(StandardProvenanceEventRecord.java:700) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:721) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.provenance.StandardProvenanceEventRecord$Builder.build(StandardProvenanceEventRecord.java:412) > ~[nifi-data-provenance-utils-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.updateProvenanceRepo(StandardProcessSession.java:634) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:295) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:283) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059) > ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123) > [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2009) StandardProcessNode and AbstractConfiguredComponent duplicate instance variable "annotationData"
[ https://issues.apache.org/jira/browse/NIFI-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328346#comment-15328346 ] Oleg Zhurakousky commented on NIFI-2009: I've seen to many nasty things in my life with such bug including one in NiFi when I started. So definitely for 0.7. It should be rather trivial to fix and as I said in the mailing list I should have a PR by tomorrow. > StandardProcessNode and AbstractConfiguredComponent duplicate instance > variable "annotationData" > > > Key: NIFI-2009 > URL: https://issues.apache.org/jira/browse/NIFI-2009 > Project: Apache NiFi > Issue Type: Bug >Reporter: Oleg Zhurakousky >Assignee: Oleg Zhurakousky > Fix For: 1.0.0, 0.7.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1722) Intermittent deadlocks in Kafka API when when stopping GetKafka
[
https://issues.apache.org/jira/browse/NIFI-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky updated NIFI-1722:
---
Fix Version/s: (was: 0.7.0)
> Intermittent deadlocks in Kafka API when when stopping GetKafka
> ---
>
> Key: NIFI-1722
> URL: https://issues.apache.org/jira/browse/NIFI-1722
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>
> It appears that Kafka gets in the state of deadlock when
> _ConsumerConnector.commitOffsets(..)_ is executed during stop call in
> GetKafka. Looking at the thread dump it may be related to the fact that we
> are shutting down consumer when onTrigger is still executing. But It also
> appears that onTrigger is in the deadlock state as well.
> Below are the relevant thread dump segments
> {code}
> "StandardProcessScheduler Thread-7" Id=115 BLOCKED on
> java.lang.Object@2baae51
> at
> kafka.consumer.ZookeeperConsumerConnector.commitOffsets(ZookeeperConsumerConnector.scala:333)
> at
> kafka.consumer.ZookeeperConsumerConnector.commitOffsets(ZookeeperConsumerConnector.scala:324)
> "ConsumerFetcherThread-74993895-50e9-3962-90e3-97af1fed7294_daves-nifi-cluster-2-1459431214410-d3b5143c-0-1001"
> Id=25120 WAITING on
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@23dc03a2
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:350)
> at
> kafka.consumer.PartitionTopicInfo.enqueue(PartitionTopicInfo.scala:60)
> at
> kafka.consumer.ConsumerFetcherThread.processPartitionData(ConsumerFetcherThread.scala:53)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$apply$3.apply(AbstractFetcherThread.scala:142)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$apply$3.apply(AbstractFetcherThread.scala:126)
> at scala.Option.foreach(Option.scala:236)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(AbstractFetcherThread.scala:126)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(AbstractFetcherThread.scala:123)
> at scala.collection.immutable.Map$Map2.foreach(Map.scala:130)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply$mcV$sp(AbstractFetcherThread.scala:123)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala:123)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala:123)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:298)
> at
> kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:122)
> at
> kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:98)
> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:60)
> Number of Locked Synchronizers: 1
> - java.util.concurrent.locks.ReentrantLock$NonfairSync@6b99259f
> "ConsumerFetcherThread-33156eec-156c-4b32-9598-d5fc3ca460ce_daves-nifi-cluster-2-1459519432175-5beddff4-0-1001"
> Id=35266 RUNNABLE (in native code)
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - waiting on java.lang.Object@3e91ba2b
> at
> sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:204)
> - waiting on java.lang.Object@494070b0
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> - waiting on sun.nio.ch.SocketAdaptor$SocketInputStream@3ade0aef
> at
> java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385)
> - waiting on java.lang.Object@7d49c744
> at kafka.utils.CoreUtils$.read(CoreUtils.scala:192)
> at
> kafka.network.BoundedByteBufferReceive.readFrom(BoundedByteBufferReceive.scala:54)
> at kafka.network.Receive$class.readCompletely(Transmission.scala:56)
> at
> kafka.network.BoundedByteBufferReceive.readCompletely(BoundedByteBufferReceive.scala:29)
> at kafka.network.BlockingChannel.receive(BlockingChannel.scala:131)
> at kafka.consumer.SimpleConsumer.liftedTree1$1(SimpleConsumer.scala:81)
> at
> kafka.consumer.SimpleConsumer.kafka$consumer$SimpleConsumer$$sendRequest(SimpleConsumer.scala:78)
> - waiting on java.lang.Object@4eba7a24
>
[jira] [Commented] (NIFI-1722) Intermittent deadlocks in Kafka API when when stopping GetKafka
[
https://issues.apache.org/jira/browse/NIFI-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328191#comment-15328191
]
Oleg Zhurakousky commented on NIFI-1722:
Technically, there is not much we can do about it outside of writing our own
custom consumer directly to the protocol possibly reusing some of the existing
low level Kafka API (something I've toyed around with).
Basically Kafka exposes blocking calls (you can see
https://issues.apache.org/jira/browse/KAFKA-2391) which are not yet addressed
and there is no ETA
> Intermittent deadlocks in Kafka API when when stopping GetKafka
> ---
>
> Key: NIFI-1722
> URL: https://issues.apache.org/jira/browse/NIFI-1722
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 0.7.0
>
>
> It appears that Kafka gets in the state of deadlock when
> _ConsumerConnector.commitOffsets(..)_ is executed during stop call in
> GetKafka. Looking at the thread dump it may be related to the fact that we
> are shutting down consumer when onTrigger is still executing. But It also
> appears that onTrigger is in the deadlock state as well.
> Below are the relevant thread dump segments
> {code}
> "StandardProcessScheduler Thread-7" Id=115 BLOCKED on
> java.lang.Object@2baae51
> at
> kafka.consumer.ZookeeperConsumerConnector.commitOffsets(ZookeeperConsumerConnector.scala:333)
> at
> kafka.consumer.ZookeeperConsumerConnector.commitOffsets(ZookeeperConsumerConnector.scala:324)
> "ConsumerFetcherThread-74993895-50e9-3962-90e3-97af1fed7294_daves-nifi-cluster-2-1459431214410-d3b5143c-0-1001"
> Id=25120 WAITING on
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@23dc03a2
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:350)
> at
> kafka.consumer.PartitionTopicInfo.enqueue(PartitionTopicInfo.scala:60)
> at
> kafka.consumer.ConsumerFetcherThread.processPartitionData(ConsumerFetcherThread.scala:53)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$apply$3.apply(AbstractFetcherThread.scala:142)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$apply$3.apply(AbstractFetcherThread.scala:126)
> at scala.Option.foreach(Option.scala:236)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(AbstractFetcherThread.scala:126)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(AbstractFetcherThread.scala:123)
> at scala.collection.immutable.Map$Map2.foreach(Map.scala:130)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply$mcV$sp(AbstractFetcherThread.scala:123)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala:123)
> at
> kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala:123)
> at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:298)
> at
> kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:122)
> at
> kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:98)
> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:60)
> Number of Locked Synchronizers: 1
> - java.util.concurrent.locks.ReentrantLock$NonfairSync@6b99259f
> "ConsumerFetcherThread-33156eec-156c-4b32-9598-d5fc3ca460ce_daves-nifi-cluster-2-1459519432175-5beddff4-0-1001"
> Id=35266 RUNNABLE (in native code)
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - waiting on java.lang.Object@3e91ba2b
> at
> sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:204)
> - waiting on java.lang.Object@494070b0
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> - waiting on sun.nio.ch.SocketAdaptor$SocketInputStream@3ade0aef
> at
> java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385)
> - waiting on java.lang.Object@7d49c744
> at kafka.utils.CoreUtils$.read(CoreUtils.scala:192)
> at
> kafka.network.BoundedByteBufferReceive.readFrom(BoundedByteBufferReceive.scala:54)
> at kafka.network.Receive$class.readCompletely(Transmission.scala:56)
> at
>
[jira] [Created] (NIFI-2009) StandardProcessNode and AbstractConfiguredComponent duplicate instance variable "annotationData"
Oleg Zhurakousky created NIFI-2009: -- Summary: StandardProcessNode and AbstractConfiguredComponent duplicate instance variable "annotationData" Key: NIFI-2009 URL: https://issues.apache.org/jira/browse/NIFI-2009 Project: Apache NiFi Issue Type: Bug Reporter: Oleg Zhurakousky Assignee: Oleg Zhurakousky Fix For: 1.0.0, 0.7.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2005) Unable to delete templates
[ https://issues.apache.org/jira/browse/NIFI-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327999#comment-15327999 ] Oleg Zhurakousky commented on NIFI-2005: This will be addressed as part of NIFI-826 > Unable to delete templates > -- > > Key: NIFI-2005 > URL: https://issues.apache.org/jira/browse/NIFI-2005 > Project: Apache NiFi > Issue Type: Bug >Reporter: Oleg Zhurakousky >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0 > > > Delete template action seem to be doing what it supposed to do (remove > template from UI). However, upon restarting NiFi (at least the current master > version) every deleted templates reappear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2005) Unable to delete templates
[ https://issues.apache.org/jira/browse/NIFI-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-2005: -- Assignee: Oleg Zhurakousky > Unable to delete templates > -- > > Key: NIFI-2005 > URL: https://issues.apache.org/jira/browse/NIFI-2005 > Project: Apache NiFi > Issue Type: Bug >Reporter: Oleg Zhurakousky >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0 > > > Delete template action seem to be doing what it supposed to do (remove > template from UI). However, upon restarting NiFi (at least the current master > version) every deleted templates reappear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2005) Unable to delete templates
[ https://issues.apache.org/jira/browse/NIFI-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327798#comment-15327798 ] Oleg Zhurakousky commented on NIFI-2005: Looking further, the templates never removed from flow.xml > Unable to delete templates > -- > > Key: NIFI-2005 > URL: https://issues.apache.org/jira/browse/NIFI-2005 > Project: Apache NiFi > Issue Type: Bug >Reporter: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0 > > > Delete template action seem to be doing what it supposed to do (remove > template from UI). However, upon restarting NiFi (at least the current master > version) every deleted templates reappear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2005) Unable to delete templates
[ https://issues.apache.org/jira/browse/NIFI-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2005: --- Fix Version/s: 1.0.0 > Unable to delete templates > -- > > Key: NIFI-2005 > URL: https://issues.apache.org/jira/browse/NIFI-2005 > Project: Apache NiFi > Issue Type: Bug >Reporter: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0 > > > Delete template action seem to be doing what it supposed to do (remove > template from UI). However, upon restarting NiFi (at least the current master > version) every deleted templates reappear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2005) Unable to delete templates
Oleg Zhurakousky created NIFI-2005: -- Summary: Unable to delete templates Key: NIFI-2005 URL: https://issues.apache.org/jira/browse/NIFI-2005 Project: Apache NiFi Issue Type: Bug Reporter: Oleg Zhurakousky Priority: Critical Delete template action seem to be doing what it supposed to do (remove template from UI). However, upon restarting NiFi (at least the current master version) every deleted templates reappear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2004) NiFi should not allow creation of templates with the same name
[ https://issues.apache.org/jira/browse/NIFI-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-2004: --- Description: NiFi allows creation of multiple templates with the same name regardless wether such templates are created from the same or different flows > NiFi should not allow creation of templates with the same name > --- > > Key: NIFI-2004 > URL: https://issues.apache.org/jira/browse/NIFI-2004 > Project: Apache NiFi > Issue Type: Bug >Reporter: Oleg Zhurakousky > Fix For: 1.0.0, 0.7.0 > > > NiFi allows creation of multiple templates with the same name regardless > wether such templates are created from the same or different flows -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2004) NiFi should not allow creation of templates with the same name
Oleg Zhurakousky created NIFI-2004: -- Summary: NiFi should not allow creation of templates with the same name Key: NIFI-2004 URL: https://issues.apache.org/jira/browse/NIFI-2004 Project: Apache NiFi Issue Type: Bug Reporter: Oleg Zhurakousky Fix For: 1.0.0, 0.7.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-1999) Remove unnecessary data from template export
Oleg Zhurakousky created NIFI-1999: -- Summary: Remove unnecessary data from template export Key: NIFI-1999 URL: https://issues.apache.org/jira/browse/NIFI-1999 Project: Apache NiFi Issue Type: Improvement Reporter: Oleg Zhurakousky Assignee: Oleg Zhurakousky Fix For: 1.0.0 Certain elements of the flow do not need to be exported into a template. This came as part of the discussion on NIFI-826. Given the complexity of NIFI-826 and unknown complexity of this effort I would prefer not to address it in a single JIRA. Still need to discuss with [~mcgilman] as to what elements do not need to be exported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1993) Upgrade CGLIB to the latest 3.2
[
https://issues.apache.org/jira/browse/NIFI-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324380#comment-15324380
]
Oleg Zhurakousky commented on NIFI-1993:
Just to connect more dots, the symptoms of this issue are very similar to
NIFI-1595. Basically improper handling of _bridge_ and _synthetic_ methods
> Upgrade CGLIB to the latest 3.2
> ---
>
> Key: NIFI-1993
> URL: https://issues.apache.org/jira/browse/NIFI-1993
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>Priority: Minor
> Fix For: 1.0.0
>
>
> While, working in NIFI-826 I've encountered problem related to Groovy tests
> (Spoke) and java 1.8 which is essentially described here:
> https://groups.google.com/forum/#!topic/spockframework/59WIHGgcSNE
> The stack trace from the failing Spoke test:
> {code}
> test InstantiateTemplate moves and scales
> templates[0](org.apache.nifi.web.dao.impl.StandardTemplateDAOSpec) Time
> elapsed: 0.46 sec <<< ERROR!
> java.lang.IllegalArgumentException: null
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
> at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
> at
> org.spockframework.mock.runtime.ProxyBasedMockFactory$CglibMockFactory.createMock(ProxyBasedMockFactory.java:91)
> at
> org.spockframework.mock.runtime.ProxyBasedMockFactory.create(ProxyBasedMockFactory.java:49)
> at
> org.spockframework.mock.runtime.JavaMockFactory.create(JavaMockFactory.java:51)
> at
> org.spockframework.mock.runtime.CompositeMockFactory.create(CompositeMockFactory.java:44)
> at
> org.spockframework.lang.SpecInternals.createMock(SpecInternals.java:45)
> at
> org.spockframework.lang.SpecInternals.createMockImpl(SpecInternals.java:281)
> at org.spockframework.lang.SpecInternals.MockImpl(SpecInternals.java:99)
> at
> groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
> at
> groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
> at
> org.apache.nifi.web.dao.impl.StandardTemplateDAOSpec$__spock_feature_0_0_closure2.closure7$_closure8(StandardTemplateDAOSpec.groovy:71)
> at groovy.lang.Closure.call(Closure.java:426)
> at
> org.spockframework.mock.response.CodeResponseGenerator.invokeClosure(CodeResponseGenerator.java:53)
> at
> org.spockframework.mock.response.CodeResponseGenerator.doRespond(CodeResponseGenerator.java:36)
> at
> org.spockframework.mock.response.SingleResponseGenerator.respond(SingleResponseGenerator.java:31)
> at
> org.spockframework.mock.response.ResponseGeneratorChain.respond(ResponseGeneratorChain.java:45)
> at
> org.spockframework.mock.runtime.MockInteraction.accept(MockInteraction.java:76)
> at
> org.spockframework.mock.runtime.MockInteractionDecorator.accept(MockInteractionDecorator.java:46)
> at
> org.spockframework.mock.runtime.InteractionScope$1.accept(InteractionScope.java:41)
> at
> org.spockframework.mock.runtime.MockController.handle(MockController.java:39)
> at
> org.spockframework.mock.runtime.JavaMockInterceptor.intercept(JavaMockInterceptor.java:72)
> at
> org.spockframework.mock.runtime.CglibMockInterceptorAdapter.intercept(CglibMockInterceptorAdapter.java:30)
> at
> org.apache.nifi.web.dao.impl.StandardTemplateDAO.instantiateTemplate(StandardTemplateDAO.java:91)
> at org.apache.nifi.web.dao.impl.StandardTemplateDAOSpec.test
> InstantiateTemplate moves and scales
> templates(StandardTemplateDAOSpec.groovy:62)
> {code}
> Upgrading to CGLIB 3.2 resolves the issue
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-1993) Upgrade CGLIB to the latest 3.2
[
https://issues.apache.org/jira/browse/NIFI-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky updated NIFI-1993:
---
Description:
While, working in NIFI-826 I've encountered problem related to Groovy tests
(Spoke) and java 1.8 which is essentially described here:
https://groups.google.com/forum/#!topic/spockframework/59WIHGgcSNE
The stack trace from the failing Spoke test:
{code}
test InstantiateTemplate moves and scales
templates[0](org.apache.nifi.web.dao.impl.StandardTemplateDAOSpec) Time
elapsed: 0.46 sec <<< ERROR!
java.lang.IllegalArgumentException: null
at
net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
at
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
at
org.spockframework.mock.runtime.ProxyBasedMockFactory$CglibMockFactory.createMock(ProxyBasedMockFactory.java:91)
at
org.spockframework.mock.runtime.ProxyBasedMockFactory.create(ProxyBasedMockFactory.java:49)
at
org.spockframework.mock.runtime.JavaMockFactory.create(JavaMockFactory.java:51)
at
org.spockframework.mock.runtime.CompositeMockFactory.create(CompositeMockFactory.java:44)
at
org.spockframework.lang.SpecInternals.createMock(SpecInternals.java:45)
at
org.spockframework.lang.SpecInternals.createMockImpl(SpecInternals.java:281)
at org.spockframework.lang.SpecInternals.MockImpl(SpecInternals.java:99)
at
groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
at
groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:46)
at
org.apache.nifi.web.dao.impl.StandardTemplateDAOSpec$__spock_feature_0_0_closure2.closure7$_closure8(StandardTemplateDAOSpec.groovy:71)
at groovy.lang.Closure.call(Closure.java:426)
at
org.spockframework.mock.response.CodeResponseGenerator.invokeClosure(CodeResponseGenerator.java:53)
at
org.spockframework.mock.response.CodeResponseGenerator.doRespond(CodeResponseGenerator.java:36)
at
org.spockframework.mock.response.SingleResponseGenerator.respond(SingleResponseGenerator.java:31)
at
org.spockframework.mock.response.ResponseGeneratorChain.respond(ResponseGeneratorChain.java:45)
at
org.spockframework.mock.runtime.MockInteraction.accept(MockInteraction.java:76)
at
org.spockframework.mock.runtime.MockInteractionDecorator.accept(MockInteractionDecorator.java:46)
at
org.spockframework.mock.runtime.InteractionScope$1.accept(InteractionScope.java:41)
at
org.spockframework.mock.runtime.MockController.handle(MockController.java:39)
at
org.spockframework.mock.runtime.JavaMockInterceptor.intercept(JavaMockInterceptor.java:72)
at
org.spockframework.mock.runtime.CglibMockInterceptorAdapter.intercept(CglibMockInterceptorAdapter.java:30)
at
org.apache.nifi.web.dao.impl.StandardTemplateDAO.instantiateTemplate(StandardTemplateDAO.java:91)
at org.apache.nifi.web.dao.impl.StandardTemplateDAOSpec.test
InstantiateTemplate moves and scales
templates(StandardTemplateDAOSpec.groovy:62)
{code}
Upgrading to CGLIB 3.2 resolves the issue
was:
While, working in NIFI-826 I've encountered problem related to Groovy tests
(Spoke) and java 1.8 which is essentially described here:
https://groups.google.com/forum/#!topic/spockframework/59WIHGgcSNE
Upgrading to CGLIB 3.2 resolves the issue
> Upgrade CGLIB to the latest 3.2
> ---
>
> Key: NIFI-1993
> URL: https://issues.apache.org/jira/browse/NIFI-1993
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>Priority: Minor
> Fix For: 1.0.0
>
>
> While, working in NIFI-826 I've encountered problem related to Groovy tests
> (Spoke) and java 1.8 which is essentially described here:
> https://groups.google.com/forum/#!topic/spockframework/59WIHGgcSNE
> The stack trace from the failing Spoke test:
> {code}
> test InstantiateTemplate moves and scales
> templates[0](org.apache.nifi.web.dao.impl.StandardTemplateDAOSpec) Time
> elapsed: 0.46 sec <<< ERROR!
> java.lang.IllegalArgumentException: null
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
>
[jira] [Created] (NIFI-1993) Upgrade CGLIB to the latest 3.2
Oleg Zhurakousky created NIFI-1993: -- Summary: Upgrade CGLIB to the latest 3.2 Key: NIFI-1993 URL: https://issues.apache.org/jira/browse/NIFI-1993 Project: Apache NiFi Issue Type: Improvement Reporter: Oleg Zhurakousky Assignee: Oleg Zhurakousky Priority: Minor Fix For: 1.0.0 While, working in NIFI-826 I've encountered problem related to Groovy tests (Spoke) and java 1.8 which is essentially described here: https://groups.google.com/forum/#!topic/spockframework/59WIHGgcSNE Upgrading to CGLIB 3.2 resolves the issue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322708#comment-15322708 ] Oleg Zhurakousky commented on NIFI-1987: Looking forward to your findings as I completely wiped off my local maven repo and did a clean build and all went fine. Further more, I've looked at all of the dependencies that were pulled in (both transient and immediate) and non were linked to anything CDH. > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > [ERROR] > [ERROR] To
[jira] [Commented] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322386#comment-15322386 ] Oleg Zhurakousky commented on NIFI-1987: [~Daniel Cave] I've looked and can't find any dependency on CDH and in fact can't reproduce the same Maven output. Is it possible that you have some local modifications to POMs (perhaps to accommodate some API dependency on CDH custom functionality)? The only CDH dependencies I see (in the entire NIFI distribution) is in Kite module which is expected. > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in >
[jira] [Commented] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321256#comment-15321256 ] Oleg Zhurakousky commented on NIFI-1987: Thanks for the heads up, I'll look into that. > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and
[jira] [Commented] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321236#comment-15321236 ] Oleg Zhurakousky commented on NIFI-1987: Also, let me know if you are willing to provide a patch/PR. > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the
[jira] [Commented] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15321234#comment-15321234 ] Oleg Zhurakousky commented on NIFI-1987: [~Daniel Cave] I've changed Affected vs. Fix versions since neither 0.7 nor 1.0 has been released yet, but will take care of it shortly. Thanks for reporting it. > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven
[jira] [Assigned] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-1987: -- Assignee: Oleg Zhurakousky > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following
[jira] [Updated] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1987: --- Fix Version/s: 0.7.0 1.0.0 > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] >
[jira] [Updated] (NIFI-1987) Nifi-Spark-Receiver build failure due to orgspark repository change
[ https://issues.apache.org/jira/browse/NIFI-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1987: --- Affects Version/s: (was: 0.7.0) (was: 1.0.0) 0.6.1 > Nifi-Spark-Receiver build failure due to orgspark repository change > --- > > Key: NIFI-1987 > URL: https://issues.apache.org/jira/browse/NIFI-1987 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 0.6.1 >Reporter: Daniel Cave >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > Builds on machines with no or incomplete local maven repos failing due to > nifi-spark-receiver sub-dependency on > oss.sonatype.org/content/repositories/orgspark-project-1113 related > dependencies. On 6/7/16 it appears that orgspark-project-1113 was removed > from the repo and was replaced with orgspark-project-1123. This blocks > complete NiFi builds where a complete local repo was not available with all > 1113 sub-dependencies already in place. See below: > [INFO] Scanning for projects... > [INFO] Inspecting build with total of 1 modules... > [INFO] Installing Nexus Staging features: > [INFO] ... total of 1 executions of maven-deploy-plugin replaced with > nexus-staging-maven-plugin > [INFO] > [INFO] > > [INFO] Building nifi-spark-receiver 0.7.0-SNAPSHOT > [INFO] > > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT.pom > [WARNING] The POM for > org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT is missing, > no dependency information available > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-site-to-site-client/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-commons/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-api/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-security-utils/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-client-dto/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-framework-bundle/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/nifi/nifi-nar-bundles/0.7.0-SNAPSHOT/maven-metadata.xml > Downloading: > http://repository.apache.org/snapshots/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > Downloading: > https://oss.sonatype.org/content/repositories/orgspark-project-1113/org/apache/avro/avro-mapred/1.7.6-cdh5.7.0-SNAPSHOT/avro-mapred-1.7.6-cdh5.7.0-SNAPSHOT-hadoop2.jar > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 6.771 s > [INFO] Finished at: 2016-06-08T13:13:41-05:00 > [INFO] Final Memory: 28M/381M > [INFO] > > [ERROR] Failed to execute goal on project nifi-spark-receiver: Could not > resolve dependencies for project > org.apache.nifi:nifi-spark-receiver:jar:0.7.0-SNAPSHOT: Could not find > artifact org.apache.avro:avro-mapred:jar:hadoop2:1.7.6-cdh5.7.0-SNAPSHOT in > apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions,
[jira] [Commented] (NIFI-826) Export templates in a deterministic way
[
https://issues.apache.org/jira/browse/NIFI-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320786#comment-15320786
]
Oleg Zhurakousky commented on NIFI-826:
---
Just continuing with some relevant notes:
After initial prototyping the _inceptionId_ approach seem to work, although I
don't like the fact that we must have _public void setInceptionId(String
inceptionId)_ to make JAXB to work. Basically it's needed for de-serialization
purposes but I want to make sure that it is not called by anyone/anything else,
so the workaround I am experimenting with now is something like this:
{code}
StackTraceElement element = Thread.currentThread().getStackTrace()[2];
if
(element.getClassName().endsWith("getInceptionId_setInceptionId_java_lang_String"))
{
this.inceptionId = UUID.fromString(inceptionId);
} else {
throw new RuntimeException("Setting inception id is not allowed since it
is generated and immutable.");
}
{code}
Basically, analyze the stack trace and see if it's called by the appropriate
component (JAXB in this case)
> Export templates in a deterministic way
> ---
>
> Key: NIFI-826
> URL: https://issues.apache.org/jira/browse/NIFI-826
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> Templates should be exported in a deterministic way so that they can be
> compared or diff'ed with another. Items to consider...
> - The ordering of components
> - The id's used to identify the components
> - Consider excluding irrelevant items. When components are imported some
> settings are ignored (run state).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (NIFI-826) Export templates in a deterministic way
[ https://issues.apache.org/jira/browse/NIFI-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15319196#comment-15319196 ] Oleg Zhurakousky edited comment on NIFI-826 at 6/7/16 7:34 PM: --- Had a talk with [~mcgilman] and I may be splitting this JIRA into two where first one would address the "deterministic" part while the second would address getting rid of elements that should not be serialized in the first place. As of right now I am playing with the additional immutable ID (as was discussed earlier). I am calling it _inceptionId_ which will be generated only once when specific DTO is created for the first time and will remain unchanged. This id will be utilized in both _hashCode()_ and _equals()_ to ensure proper ordering. [~mcgilman] [~rpmiskin] - let me know your thoughts was (Author: ozhurakousky): Had a talk with [~mcgilman] and I amy be splitting this JIRA into two where first one would address the "deterministic" part while the second would address getting rid of elements that should not be serialized in the first place. As of right now I am playing with the additional immutable ID (as was discussed earlier). I am calling it _inceptionId_ which will be generated only once when specific DTO is created for the first time and will remain unchanged. This id will be utilized in both _hashCode()_ and _equals()_ to ensure proper ordering. [~mcgilman] [~rpmiskin] - let me know your thoughts > Export templates in a deterministic way > --- > > Key: NIFI-826 > URL: https://issues.apache.org/jira/browse/NIFI-826 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > Templates should be exported in a deterministic way so that they can be > compared or diff'ed with another. Items to consider... > - The ordering of components > - The id's used to identify the components > - Consider excluding irrelevant items. When components are imported some > settings are ignored (run state). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-826) Export templates in a deterministic way
[ https://issues.apache.org/jira/browse/NIFI-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15319196#comment-15319196 ] Oleg Zhurakousky commented on NIFI-826: --- Had a talk with [~mcgilman] and I amy be splitting this JIRA into two where first one would address the "deterministic" part while the second would address getting rid of elements that should not be serialized in the first place. As of right now I am playing with the additional immutable ID (as was discussed earlier). I am calling it _inceptionId_ which will be generated only once when specific DTO is created for the first time and will remain unchanged. This id will be utilized in both _hashCode()_ and _equals()_ to ensure proper ordering. [~mcgilman] [~rpmiskin] - let me know your thoughts > Export templates in a deterministic way > --- > > Key: NIFI-826 > URL: https://issues.apache.org/jira/browse/NIFI-826 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > Templates should be exported in a deterministic way so that they can be > compared or diff'ed with another. Items to consider... > - The ordering of components > - The id's used to identify the components > - Consider excluding irrelevant items. When components are imported some > settings are ignored (run state). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1926) Create a general purpose Aggregating processor
[ https://issues.apache.org/jira/browse/NIFI-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15319127#comment-15319127 ] Oleg Zhurakousky commented on NIFI-1926: As I am gathering use cases I wanted to share a discussion I had with [~aperepel] where he shared an interesting yet common use case: Basically somewhat of a classic _scatter-gather_ where aggregation would only need to be performed on FlowFile attributes while content remains unchanged. Picture the same FlowFile being sent to multiple consumers (classic pub-sub) where each consumer would update/create some attributes. Content of such FlowFile is not changing and the requirement is to have an output FlowFile contain aggregated attributes from all requests while maintaining the same content. And even if content were to change in some way, the core value here is that by having pluggable aggregation strategy user can/should be able to specify how content should be aggregated (e.g., merge/concatenate or use content from any flow file or even create a whole new content). > Create a general purpose Aggregating processor > -- > > Key: NIFI-1926 > URL: https://issues.apache.org/jira/browse/NIFI-1926 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Oleg Zhurakousky >Assignee: Oleg Zhurakousky > > Based on multiple question on mailing list it appears that we need to have a > general purpose processor to aggregate data (FlowFiles or content of > FlowFiles etc). Basically provide an implementation of this > http://www.enterpriseintegrationpatterns.com/patterns/messaging/Aggregator.html > Keep in mind that while MergeContent processor could be looked at as one of > the variation of aggregation, the pattern and the problem has much more > moving parts that need to be addressed (release, correlation, and aggregation > strategies). So the new processor should be flexible enough to handle variety > of aggregation use cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1956) Add "keyboard-interactive" option to SFTPTransfer
[
https://issues.apache.org/jira/browse/NIFI-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15317051#comment-15317051
]
Oleg Zhurakousky commented on NIFI-1956:
[~mosermw] Yes, that is the idea. Just to elaborate on it a little more; Most
SSH servers do support "keyboard-interactive". That is what allows us to login
using userid and prompted for a password. The actual "password" authentication
method means (if I understand it correctly) the ability to provide password
right away. I am assuming something like this _ssh user:password@host_. That
would imply the password would go out in clear text. The
"keyboard-authentication" will actually prompt you for a password and that is
what RFC-4256 is all about and most SSH servers support it, otherwise we
wouldn't be able to connect to it using password. That said, to avoid being
prompted JSch provides the the authentication provider implementation which
will intercept the prompt and will use password provided via properties
essentially accomplishing the same thing as "password" method.
> Add "keyboard-interactive" option to SFTPTransfer
> -
>
> Key: NIFI-1956
> URL: https://issues.apache.org/jira/browse/NIFI-1956
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0, 0.7.0
>
>
> With RFC-4256 some SSH servers may no longer support or enable "password" as
> a valid authentication option in favor of "keyboard-interactive".
> This results in
> {code}
> Exception in thread "main" com.jcraft.jsch.JSchException: Auth fail
> {code}
> And even though the spec discusses the authentication mechanism where user
> will be prompted for a password, JSch provides an authentication provider
> which handles such prompt behind the scenes as long as user sets password in
> a session.
> Belo code shows how to reproduce the issue (at least in osx):
> {code}
> public static void main(String[] args) throws Exception {
> JSch jsch = new JSch();
> Session session = jsch.getSession("", "localhost", 22);
> session.setPassword("");
> Properties properties = new Properties();
> properties.setProperty("StrictHostKeyChecking", "no");
> //properties.setProperty("PreferredAuthentications",
> "publickey,password,keyboard-interactive");
> properties.setProperty("PreferredAuthentications",
> "publickey,password");
> session.setConfig(properties);
> session.connect();
> System.out.println("connected");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-1668) Intermittent Test Failure for TestProcessorLifecycle
[ https://issues.apache.org/jira/browse/NIFI-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1668: --- Fix Version/s: 1.0.0 > Intermittent Test Failure for TestProcessorLifecycle > > > Key: NIFI-1668 > URL: https://issues.apache.org/jira/browse/NIFI-1668 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Bende >Assignee: Oleg Zhurakousky >Priority: Minor > Fix For: 1.0.0, 0.7.0 > > > A build on Travis produced the errors below, but they are not seen frequently: > validateProcessorCanBeStoppedWhenOnTriggerThrowsException on > validateProcessorCanBeStoppedWhenOnTriggerThrowsException(org.apache.nifi.controller.scheduling.TestProcessorLifecycle)(org.apache.nifi.controller.scheduling.TestProcessorLifecycle) > Time elapsed: 0.085 sec <<< FAILURE! > java.nio.channels.OverlappingFileLockException: null > at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) > at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152) > at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1043) > at java.nio.channels.FileChannel.lock(FileChannel.java:1052) > at > org.wali.MinimalLockingWriteAheadLog.(MinimalLockingWriteAheadLog.java:179) > at > org.wali.MinimalLockingWriteAheadLog.(MinimalLockingWriteAheadLog.java:108) > at > org.apache.nifi.controller.state.providers.local.WriteAheadLocalStateProvider.init(WriteAheadLocalStateProvider.java:97) > at > org.apache.nifi.controller.state.providers.AbstractStateProvider.initialize(AbstractStateProvider.java:34) > at > org.apache.nifi.controller.state.manager.StandardStateManagerProvider.createStateProvider(StandardStateManagerProvider.java:186) > at > org.apache.nifi.controller.state.manager.StandardStateManagerProvider.createLocalStateProvider(StandardStateManagerProvider.java:80) > at > org.apache.nifi.controller.state.manager.StandardStateManagerProvider.create(StandardStateManagerProvider.java:66) > at > org.apache.nifi.controller.FlowController.(FlowController.java:435) > at > org.apache.nifi.controller.FlowController.createStandaloneInstance(FlowController.java:366) > at > org.apache.nifi.controller.scheduling.TestProcessorLifecycle.buildFlowControllerForTest(TestProcessorLifecycle.java:642) > at > org.apache.nifi.controller.scheduling.TestProcessorLifecycle.validateProcessorCanBeStoppedWhenOnTriggerThrowsException(TestProcessorLifecycle.java:477) > Results : > Failed tests: > > TestProcessorLifecycle.validateDisableOperation:117->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateLifecycleOperationOrderWithConcurrentCallsToStartStop:254->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateProcessScheduledAfterAdministrativeDelayDueToTheOnScheduledException:347->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateProcessorCanBeStoppedWhenOnScheduledBlocksIndefinitelyInterruptable:413->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateProcessorCanBeStoppedWhenOnScheduledBlocksIndefinitelyUninterruptable:443->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateProcessorCanBeStoppedWhenOnScheduledConstantlyFails:380->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateProcessorCanBeStoppedWhenOnTriggerThrowsException:477->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateProcessorUnscheduledAndStoppedWhenStopIsCalledBeforeProcessorFullyStarted:311->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateStartSucceedsOnProcessorWithEnabledService:554->buildFlowControllerForTest:642 > » OverlappingFileLock > > TestProcessorLifecycle.validateStopCallsAreMeaninglessIfProcessorNotStarted:187->buildFlowControllerForTest:642 > » OverlappingFileLock > TestProcessorLifecycle.validateSuccessfullAndOrderlyShutdown:239 > expected:<3> but was:<2> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1690) Misconfigured MonitorMemory ReportingTask can not be stopped
[ https://issues.apache.org/jira/browse/NIFI-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1690: --- Fix Version/s: 1.0.0 > Misconfigured MonitorMemory ReportingTask can not be stopped > > > Key: NIFI-1690 > URL: https://issues.apache.org/jira/browse/NIFI-1690 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.5.1 >Reporter: Matthew Clarke >Assignee: Oleg Zhurakousky > Fix For: 1.0.0, 0.7.0 > > > The monitor memory reporting tasks allows the user to entire any value > they want for the JVM memory pool. If the supplied value is not valid (NiFi > can not find a memory pool with the supplied value), the reporting tasks > appears to get stuck in the @onDemand state. At this point the task can not > be stopped, edited, or deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1925) Typo in out of memory Error Message in ProvenanceRepository
[ https://issues.apache.org/jira/browse/NIFI-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1925: --- Fix Version/s: 0.7.0 1.0.0 > Typo in out of memory Error Message in ProvenanceRepository > --- > > Key: NIFI-1925 > URL: https://issues.apache.org/jira/browse/NIFI-1925 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Simon Elliston Ball >Priority: Trivial > Labels: easyfix > Fix For: 1.0.0, 0.7.0 > > > This most often happens as a result of the repository running out of disk > space or the JMV running out of memory. > should read > This most often happens as a result of the repository running out of disk > space or the JVM running out of memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1964) Persist flow.xml.gz on start-up so root group id is persisted
[ https://issues.apache.org/jira/browse/NIFI-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314135#comment-15314135 ] Oleg Zhurakousky commented on NIFI-1964: I see now. Make sence > Persist flow.xml.gz on start-up so root group id is persisted > - > > Key: NIFI-1964 > URL: https://issues.apache.org/jira/browse/NIFI-1964 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core Framework >Reporter: Bryan Bende >Priority: Minor > Fix For: 1.0.0 > > > Currently the flow.xml.gz is only persisted after someone accesses the UI and > takes an action like adding a processor or component. This means that if you > keep restarting NiFi without touching the UI, it will generate a different > root group id each time. > For the authorization refactoring we need to be able to access the root group > id on start up and know that it is going to be consistent regardless of > whether the UI has been accessed. We should persist the initial flow.xml.gz > after the root group id is generated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1926) Create a general purpose Aggregating processor
[ https://issues.apache.org/jira/browse/NIFI-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15314046#comment-15314046 ] Oleg Zhurakousky commented on NIFI-1926: Sure [~markap14]. So recently couple of use cases have been discussed on the list, so I'll list some that I remember: 1. Correlating the input coming from multiple upstream connections 2. Configurable aggregation strategies (I may not want to merge, rather output a collection of FF) 3. Time-based batches (e.g., release what you've accumulated for a particular correlation ID every 5 sec) I'll list more as I remember. > Create a general purpose Aggregating processor > -- > > Key: NIFI-1926 > URL: https://issues.apache.org/jira/browse/NIFI-1926 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Oleg Zhurakousky >Assignee: Oleg Zhurakousky > > Based on multiple question on mailing list it appears that we need to have a > general purpose processor to aggregate data (FlowFiles or content of > FlowFiles etc). Basically provide an implementation of this > http://www.enterpriseintegrationpatterns.com/patterns/messaging/Aggregator.html > Keep in mind that while MergeContent processor could be looked at as one of > the variation of aggregation, the pattern and the problem has much more > moving parts that need to be addressed (release, correlation, and aggregation > strategies). So the new processor should be flexible enough to handle variety > of aggregation use cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1956) Add "keyboard-interactive" option to SFTPTransfer
[
https://issues.apache.org/jira/browse/NIFI-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky updated NIFI-1956:
---
Fix Version/s: 0.7.0
1.0.0
> Add "keyboard-interactive" option to SFTPTransfer
> -
>
> Key: NIFI-1956
> URL: https://issues.apache.org/jira/browse/NIFI-1956
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0, 0.7.0
>
>
> With RFC-4256 some SSH servers may no longer support or enable "password" as
> a valid authentication option in favor of "keyboard-interactive".
> This results in
> {code}
> Exception in thread "main" com.jcraft.jsch.JSchException: Auth fail
> {code}
> And even though the spec discusses the authentication mechanism where user
> will be prompted for a password, JSch provides an authentication provider
> which handles such prompt behind the scenes as long as user sets password in
> a session.
> Belo code shows how to reproduce the issue (at least in osx):
> {code}
> public static void main(String[] args) throws Exception {
> JSch jsch = new JSch();
> Session session = jsch.getSession("", "localhost", 22);
> session.setPassword("");
> Properties properties = new Properties();
> properties.setProperty("StrictHostKeyChecking", "no");
> //properties.setProperty("PreferredAuthentications",
> "publickey,password,keyboard-interactive");
> properties.setProperty("PreferredAuthentications",
> "publickey,password");
> session.setConfig(properties);
> session.connect();
> System.out.println("connected");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-1956) Add "keyboard-interactive" option to SFTPTransfer
[
https://issues.apache.org/jira/browse/NIFI-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky updated NIFI-1956:
---
Description:
With RFC-4256 some SSH servers may no longer support or enable "password" as a
valid authentication option in favor of "keyboard-interactive".
This results in
{code}
Exception in thread "main" com.jcraft.jsch.JSchException: Auth fail
{code}
And even though the spec discusses the authentication mechanism where user will
be prompted for a password, JSch provides an authentication provider which
handles such prompt behind the scenes as long as user sets password in a
session.
Belo code shows how to reproduce the issue (at least in osx):
{code}
public static void main(String[] args) throws Exception {
JSch jsch = new JSch();
Session session = jsch.getSession("", "localhost", 22);
session.setPassword("");
Properties properties = new Properties();
properties.setProperty("StrictHostKeyChecking", "no");
//properties.setProperty("PreferredAuthentications",
"publickey,password,keyboard-interactive");
properties.setProperty("PreferredAuthentications",
"publickey,password");
session.setConfig(properties);
session.connect();
System.out.println("connected");
}
{code}
was:
With RFC-4256 some SSH servers may no longer support or enable "password" as a
valid authentication option in favor of "keyboard-interactive".
This results in
{code}
Exception in thread "main" com.jcraft.jsch.JSchException: Auth fail
{code}
And even though the spec discusses the authentication mechanism where user will
be prompted for a password, JSch provides an authentication provider which
handles such prompt behind the scenes as long as user sets password in a
session.
Belo code shows how to reproduce the issue (at least in osx):
{code}
public static void main(String[] args) throws Exception {
JSch jsch = new JSch();
Session session = jsch.getSession("", "localhost", 22);
session.setPassword("");
Properties properties = new Properties();
properties.setProperty("StrictHostKeyChecking", "no");
//properties.setProperty("PreferredAuthentications",
"publickey,password,keyboard-interactive");
properties.setProperty("PreferredAuthentications",
"publickey,password");
session.setConfig(properties);
session.connect();
System.out.println("connected");
}
> Add "keyboard-interactive" option to SFTPTransfer
> -
>
> Key: NIFI-1956
> URL: https://issues.apache.org/jira/browse/NIFI-1956
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
>
> With RFC-4256 some SSH servers may no longer support or enable "password" as
> a valid authentication option in favor of "keyboard-interactive".
> This results in
> {code}
> Exception in thread "main" com.jcraft.jsch.JSchException: Auth fail
> {code}
> And even though the spec discusses the authentication mechanism where user
> will be prompted for a password, JSch provides an authentication provider
> which handles such prompt behind the scenes as long as user sets password in
> a session.
> Belo code shows how to reproduce the issue (at least in osx):
> {code}
> public static void main(String[] args) throws Exception {
> JSch jsch = new JSch();
> Session session = jsch.getSession("", "localhost", 22);
> session.setPassword("");
> Properties properties = new Properties();
> properties.setProperty("StrictHostKeyChecking", "no");
> //properties.setProperty("PreferredAuthentications",
> "publickey,password,keyboard-interactive");
> properties.setProperty("PreferredAuthentications",
> "publickey,password");
> session.setConfig(properties);
> session.connect();
> System.out.println("connected");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (NIFI-1956) Add "keyboard-interactive" option to SFTPTransfer
Oleg Zhurakousky created NIFI-1956:
--
Summary: Add "keyboard-interactive" option to SFTPTransfer
Key: NIFI-1956
URL: https://issues.apache.org/jira/browse/NIFI-1956
Project: Apache NiFi
Issue Type: Improvement
Affects Versions: 1.0.0, 0.7.0
Reporter: Oleg Zhurakousky
Assignee: Oleg Zhurakousky
With RFC-4256 some SSH servers may no longer support or enable "password" as a
valid authentication option in favor of "keyboard-interactive".
This results in
{code}
Exception in thread "main" com.jcraft.jsch.JSchException: Auth fail
{code}
And even though the spec discusses the authentication mechanism where user will
be prompted for a password, JSch provides an authentication provider which
handles such prompt behind the scenes as long as user sets password in a
session.
Belo code shows how to reproduce the issue (at least in osx):
{code}
public static void main(String[] args) throws Exception {
JSch jsch = new JSch();
Session session = jsch.getSession("", "localhost", 22);
session.setPassword("");
Properties properties = new Properties();
properties.setProperty("StrictHostKeyChecking", "no");
//properties.setProperty("PreferredAuthentications",
"publickey,password,keyboard-interactive");
properties.setProperty("PreferredAuthentications",
"publickey,password");
session.setConfig(properties);
session.connect();
System.out.println("connected");
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-826) Export templates in a deterministic way
[ https://issues.apache.org/jira/browse/NIFI-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-826: -- Fix Version/s: 1.0.0 > Export templates in a deterministic way > --- > > Key: NIFI-826 > URL: https://issues.apache.org/jira/browse/NIFI-826 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > Templates should be exported in a deterministic way so that they can be > compared or diff'ed with another. Items to consider... > - The ordering of components > - The id's used to identify the components > - Consider excluding irrelevant items. When components are imported some > settings are ignored (run state). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-826) Export templates in a deterministic way
[ https://issues.apache.org/jira/browse/NIFI-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-826: - Assignee: Oleg Zhurakousky (was: Matt Gilman) > Export templates in a deterministic way > --- > > Key: NIFI-826 > URL: https://issues.apache.org/jira/browse/NIFI-826 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Oleg Zhurakousky > Fix For: 1.0.0 > > > Templates should be exported in a deterministic way so that they can be > compared or diff'ed with another. Items to consider... > - The ordering of components > - The id's used to identify the components > - Consider excluding irrelevant items. When components are imported some > settings are ignored (run state). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1915) ReplaceText infinite loops when attribute contains $ sign
[ https://issues.apache.org/jira/browse/NIFI-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15303402#comment-15303402 ] Oleg Zhurakousky commented on NIFI-1915: Yep, in the end it all worked out and the minor bug was fixed! Thank you! > ReplaceText infinite loops when attribute contains $ sign > - > > Key: NIFI-1915 > URL: https://issues.apache.org/jira/browse/NIFI-1915 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > I think the biggest issue is that the text inside of an attribute isn't > properly escaped when written to a String, which brings conflict when the > text contains dollar signs ($) > That's a big roadblock for me as I can't predict if and when some $ signs may > be present in the data > An easy way to reproduce is to take the csv to json template here: > https://cwiki.apache.org/confluence/download/attachments/57904847/CsvToJSON.xml?version=1=1442927496000=v2 > > In the first ReplaceText, replace a,b,c,d by a$a,b,c,d (it simulates data > that may or may not contain a $ sign) > Launch the flow, you'll see the errors / warning / infinite loop -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-1926) Create a general purpose Aggregating processor
Oleg Zhurakousky created NIFI-1926: -- Summary: Create a general purpose Aggregating processor Key: NIFI-1926 URL: https://issues.apache.org/jira/browse/NIFI-1926 Project: Apache NiFi Issue Type: New Feature Reporter: Oleg Zhurakousky Assignee: Oleg Zhurakousky Based on multiple question on mailing list it appears that we need to have a general purpose processor to aggregate data (FlowFiles or content of FlowFiles etc). Basically provide an implementation of this http://www.enterpriseintegrationpatterns.com/patterns/messaging/Aggregator.html Keep in mind that while MergeContent processor could be looked at as one of the variation of aggregation, the pattern and the problem has much more moving parts that need to be addressed (release, correlation, and aggregation strategies). So the new processor should be flexible enough to handle variety of aggregation use cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1915) ReplaceText infinite loops when attribute contains $ sign
[ https://issues.apache.org/jira/browse/NIFI-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301983#comment-15301983 ] Oleg Zhurakousky commented on NIFI-1915: Stephane I think you are missing one important element of this processor. The REPLACEMENT_VALUE will rely on the _Replacement Strategy_ which defaults to regex replace. But it looks like (from your explanation) you expect and require _literal_ replace. For that all you need to configure is one additional property to override _Replacement Strategy_.property and set its value to *Literal Replace*. Let us know Cheers > ReplaceText infinite loops when attribute contains $ sign > - > > Key: NIFI-1915 > URL: https://issues.apache.org/jira/browse/NIFI-1915 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > I think the biggest issue is that the text inside of an attribute isn't > properly escaped when written to a String, which brings conflict when the > text contains dollar signs ($) > That's a big roadblock for me as I can't predict if and when some $ signs may > be present in the data > An easy way to reproduce is to take the csv to json template here: > https://cwiki.apache.org/confluence/download/attachments/57904847/CsvToJSON.xml?version=1=1442927496000=v2 > > In the first ReplaceText, replace a,b,c,d by a$a,b,c,d (it simulates data > that may or may not contain a $ sign) > Launch the flow, you'll see the errors / warning / infinite loop -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1915) ReplaceText infinite loops when attribute contains $ sign
[ https://issues.apache.org/jira/browse/NIFI-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1529#comment-1529 ] Oleg Zhurakousky commented on NIFI-1915: Stephane Wasn't thinking clearly last night. The _$_ is a special character and while we try our best to determine intention of the user, when you send '$number' (backreference) we can't assume you want it to be treated literally as someone else would have an opposite expectation. Since it comes as an attribute in your code, I'd suggest to introduce UpdateAttribute upstream and update the attribute string 'a$2' with escape characters before sending it to ReplaceText. Anyway, i'll resubmit PR as of yesterday with no additional changes. Yet, let us know your thoughts. > ReplaceText infinite loops when attribute contains $ sign > - > > Key: NIFI-1915 > URL: https://issues.apache.org/jira/browse/NIFI-1915 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > I think the biggest issue is that the text inside of an attribute isn't > properly escaped when written to a String, which brings conflict when the > text contains dollar signs ($) > That's a big roadblock for me as I can't predict if and when some $ signs may > be present in the data > An easy way to reproduce is to take the csv to json template here: > https://cwiki.apache.org/confluence/download/attachments/57904847/CsvToJSON.xml?version=1=1442927496000=v2 > > In the first ReplaceText, replace a,b,c,d by a$a,b,c,d (it simulates data > that may or may not contain a $ sign) > Launch the flow, you'll see the errors / warning / infinite loop -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1915) ReplaceText infinite loops when attribute contains $ sign
[ https://issues.apache.org/jira/browse/NIFI-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299236#comment-15299236 ] Oleg Zhurakousky commented on NIFI-1915: Good point, let me work on that. > ReplaceText infinite loops when attribute contains $ sign > - > > Key: NIFI-1915 > URL: https://issues.apache.org/jira/browse/NIFI-1915 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > I think the biggest issue is that the text inside of an attribute isn't > properly escaped when written to a String, which brings conflict when the > text contains dollar signs ($) > That's a big roadblock for me as I can't predict if and when some $ signs may > be present in the data > An easy way to reproduce is to take the csv to json template here: > https://cwiki.apache.org/confluence/download/attachments/57904847/CsvToJSON.xml?version=1=1442927496000=v2 > > In the first ReplaceText, replace a,b,c,d by a$a,b,c,d (it simulates data > that may or may not contain a $ sign) > Launch the flow, you'll see the errors / warning / infinite loop -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-710) Enumerate available Hadoop library versions for GetHDFS and PutHDFS
[ https://issues.apache.org/jira/browse/NIFI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-710: -- Fix Version/s: (was: 1.0.0) > Enumerate available Hadoop library versions for GetHDFS and PutHDFS > --- > > Key: NIFI-710 > URL: https://issues.apache.org/jira/browse/NIFI-710 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions > Environment: Unix, Hadoop >Reporter: Nathan Gough >Assignee: Oleg Zhurakousky >Priority: Minor > Labels: hadoop, hdfs, library > > As far as I'm aware, it is only possible to use a single Hadoop library > version per NiFi instance/cluster. > Would it be possible in some way to enumerate the available Hadoop library > versions in the /lib directory and give the user the option to select which > version of Hadoop cluster they are writing to or reading from per HDFS > processor? The intent would be to allow a single NiFi instance/cluster to > write to multiple HDFS clusters which may be running on different versions > eg. QA and Prod. This eliminates the need for having multiple HDFS feeder > NiFis only because the Hadoop versions are different. > I would try and figure this out my self however I don't know a whole lot > about class loading in NiFi or generally how I would start this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1808) Create General MQTT Processors
[ https://issues.apache.org/jira/browse/NIFI-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1808: --- Fix Version/s: 0.7.0 1.0.0 > Create General MQTT Processors > -- > > Key: NIFI-1808 > URL: https://issues.apache.org/jira/browse/NIFI-1808 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.0.0, 0.7.0 > > > MQTT[1] is a great "Internet of Things" (IoT) connectivity protocol that > implementing processors for would allow NiFi to continue expanding into the > IoT domain. A prime opportunity would be to use in conjunction with Apache > NiFi - MiNiFi. > [1] http://mqtt.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-1915) ReplaceText infinite loops when attribute contains $ sign
[ https://issues.apache.org/jira/browse/NIFI-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky reassigned NIFI-1915: -- Assignee: Oleg Zhurakousky > ReplaceText infinite loops when attribute contains $ sign > - > > Key: NIFI-1915 > URL: https://issues.apache.org/jira/browse/NIFI-1915 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > I think the biggest issue is that the text inside of an attribute isn't > properly escaped when written to a String, which brings conflict when the > text contains dollar signs ($) > That's a big roadblock for me as I can't predict if and when some $ signs may > be present in the data > An easy way to reproduce is to take the csv to json template here: > https://cwiki.apache.org/confluence/download/attachments/57904847/CsvToJSON.xml?version=1=1442927496000=v2 > > In the first ReplaceText, replace a,b,c,d by a$a,b,c,d (it simulates data > that may or may not contain a $ sign) > Launch the flow, you'll see the errors / warning / infinite loop -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1915) ReplaceText infinite loops when attribute contains $ sign
[ https://issues.apache.org/jira/browse/NIFI-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Zhurakousky updated NIFI-1915: --- Fix Version/s: 0.7.0 1.0.0 > ReplaceText infinite loops when attribute contains $ sign > - > > Key: NIFI-1915 > URL: https://issues.apache.org/jira/browse/NIFI-1915 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek >Assignee: Oleg Zhurakousky >Priority: Critical > Fix For: 1.0.0, 0.7.0 > > > I think the biggest issue is that the text inside of an attribute isn't > properly escaped when written to a String, which brings conflict when the > text contains dollar signs ($) > That's a big roadblock for me as I can't predict if and when some $ signs may > be present in the data > An easy way to reproduce is to take the csv to json template here: > https://cwiki.apache.org/confluence/download/attachments/57904847/CsvToJSON.xml?version=1=1442927496000=v2 > > In the first ReplaceText, replace a,b,c,d by a$a,b,c,d (it simulates data > that may or may not contain a $ sign) > Launch the flow, you'll see the errors / warning / infinite loop -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-1905) Stop action doesn't invoke ExecuteProcess.destroy()
[
https://issues.apache.org/jira/browse/NIFI-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky updated NIFI-1905:
---
Fix Version/s: 0.7.0
1.0.0
> Stop action doesn't invoke ExecuteProcess.destroy()
> ---
>
> Key: NIFI-1905
> URL: https://issues.apache.org/jira/browse/NIFI-1905
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 0.6.1
> Environment: Raspberry Pi 3
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
>Reporter: Andrew Grande
>Priority: Critical
> Fix For: 1.0.0, 0.7.0
>
> Attachments: NIFI-1905.xml
>
>
> Consider the attached template. There is an ExecuteProcess which wraps a
> python script (listed below).
> STR:
> * start ListenTcp
> * start ExecuteProcess
> * stop ExecuteProcess
> Expected: the ExecuteProcess component terminates successfully
> Actual: there's always a thread running (1 displayed in the top-right corner
> of the processor)
> The thread will only go away if the underlying command crashes. It's easy to
> replicate by stopping ListenTcp - the script will fail with a socket
> connection error and quit.
> I have been looking into the ExecuteProcess source, and it looks like
> OnUnscheduled must also invoke Process.destroy() in addition to terminating
> the stdio/stderr I/O threads, but there's nothing like that anywhere.
> {code}
> import serial
> import socket
> # set up the serial connection speed
> ser = serial.Serial('/dev/ttyUSB0', 115200)
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('localhost',3456))
> # main loop
> while 1:
> data = ser.readline()
> s.sendall(data)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (NIFI-1905) Stop action doesn't invoke ExecuteProcess.destroy()
[
https://issues.apache.org/jira/browse/NIFI-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky reassigned NIFI-1905:
--
Assignee: Oleg Zhurakousky
> Stop action doesn't invoke ExecuteProcess.destroy()
> ---
>
> Key: NIFI-1905
> URL: https://issues.apache.org/jira/browse/NIFI-1905
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 0.6.1
> Environment: Raspberry Pi 3
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
>Reporter: Andrew Grande
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.0.0, 0.7.0
>
> Attachments: NIFI-1905.xml
>
>
> Consider the attached template. There is an ExecuteProcess which wraps a
> python script (listed below).
> STR:
> * start ListenTcp
> * start ExecuteProcess
> * stop ExecuteProcess
> Expected: the ExecuteProcess component terminates successfully
> Actual: there's always a thread running (1 displayed in the top-right corner
> of the processor)
> The thread will only go away if the underlying command crashes. It's easy to
> replicate by stopping ListenTcp - the script will fail with a socket
> connection error and quit.
> I have been looking into the ExecuteProcess source, and it looks like
> OnUnscheduled must also invoke Process.destroy() in addition to terminating
> the stdio/stderr I/O threads, but there's nothing like that anywhere.
> {code}
> import serial
> import socket
> # set up the serial connection speed
> ser = serial.Serial('/dev/ttyUSB0', 115200)
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('localhost',3456))
> # main loop
> while 1:
> data = ser.readline()
> s.sendall(data)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NIFI-1898) Flume Processors can not be started
[
https://issues.apache.org/jira/browse/NIFI-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15291129#comment-15291129
]
Oleg Zhurakousky commented on NIFI-1898:
Part of the issue is that it was not caught in unit tests due to the fact that
NiFi mock has deviated from non-mock execution/life-cycle framework.
For this specific case we have two classes with name MockProcessContext that
have different base type hierarchy. But most importantly the types that are
used in tests are not always the types that are used in regular NiFi operations
> Flume Processors can not be started
> ---
>
> Key: NIFI-1898
> URL: https://issues.apache.org/jira/browse/NIFI-1898
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 0.6.1
>Reporter: Bryan Bende
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0, 0.7.0
>
>
> When trying to use ExecuteFlumeSource, the following error was encountered:
> {code}
> 2016-05-18 14:06:14,338 ERROR [StandardProcessScheduler Thread-5]
> org.apache.nifi.util.ReflectionUtils Can not invoke method 'public void
> org.apache.nifi.processors.flume.ExecuteFlumeSource.onScheduled(org.apache.nifi.processor.SchedulingContext)'
> with provided arguments since argument 0 of type 'interface
> org.apache.nifi.processor.SchedulingContext' is not assignable from provided
> value of type 'class org.apache.nifi.processor.StandardProcessContext'.
> 2016-05-18 14:06:14,338 ERROR [StandardProcessScheduler Thread-2]
> o.a.n.p.flume.ExecuteFlumeSource
> ExecuteFlumeSource[id=df4a6e2d-be59-448a-857b-5e88df88052e]
> ExecuteFlumeSource[id=df4a6e2d-be59-448a-857b-5e88df88052e] failed to invoke
> @OnScheduled method due to java.lang.RuntimeException: Failed while executing
> one of processor's OnScheduled task.; processor will not be scheduled to run
> for 3 milliseconds: java.lang.RuntimeException: Failed while executing
> one of processor's OnScheduled task.
> 2016-05-18 14:06:14,340 ERROR [StandardProcessScheduler Thread-5]
> org.apache.nifi.engine.FlowEngine A flow controller task execution stopped
> abnormally
> java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException:
> argument type mismatch
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> ~[na:1.8.0_74]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> ~[na:1.8.0_74]
> at org.apache.nifi.engine.FlowEngine.afterExecute(FlowEngine.java:100)
> ~[na:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1150)
> [na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_74]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_74]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_74]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_74]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_74]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
> ~[na:na]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
> ~[na:na]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70)
> ~[na:na]
> at
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1247)
> ~[na:na]
> at
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1243)
> ~[na:na]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_74]
> ... 2 common frames omitted
> {code}
> It looks like at some point we switched from using SchedulingContext to
> ProcessContext for methods annotated with @OnScheduled but somehow these
> processors were never updated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (NIFI-1898) Flume Processors can not be started
[
https://issues.apache.org/jira/browse/NIFI-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky reassigned NIFI-1898:
--
Assignee: Oleg Zhurakousky
> Flume Processors can not be started
> ---
>
> Key: NIFI-1898
> URL: https://issues.apache.org/jira/browse/NIFI-1898
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 0.6.1
>Reporter: Bryan Bende
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0, 0.7.0
>
>
> When trying to use ExecuteFlumeSource, the following error was encountered:
> {code}
> 2016-05-18 14:06:14,338 ERROR [StandardProcessScheduler Thread-5]
> org.apache.nifi.util.ReflectionUtils Can not invoke method 'public void
> org.apache.nifi.processors.flume.ExecuteFlumeSource.onScheduled(org.apache.nifi.processor.SchedulingContext)'
> with provided arguments since argument 0 of type 'interface
> org.apache.nifi.processor.SchedulingContext' is not assignable from provided
> value of type 'class org.apache.nifi.processor.StandardProcessContext'.
> 2016-05-18 14:06:14,338 ERROR [StandardProcessScheduler Thread-2]
> o.a.n.p.flume.ExecuteFlumeSource
> ExecuteFlumeSource[id=df4a6e2d-be59-448a-857b-5e88df88052e]
> ExecuteFlumeSource[id=df4a6e2d-be59-448a-857b-5e88df88052e] failed to invoke
> @OnScheduled method due to java.lang.RuntimeException: Failed while executing
> one of processor's OnScheduled task.; processor will not be scheduled to run
> for 3 milliseconds: java.lang.RuntimeException: Failed while executing
> one of processor's OnScheduled task.
> 2016-05-18 14:06:14,340 ERROR [StandardProcessScheduler Thread-5]
> org.apache.nifi.engine.FlowEngine A flow controller task execution stopped
> abnormally
> java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException:
> argument type mismatch
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> ~[na:1.8.0_74]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> ~[na:1.8.0_74]
> at org.apache.nifi.engine.FlowEngine.afterExecute(FlowEngine.java:100)
> ~[na:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1150)
> [na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_74]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_74]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_74]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_74]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_74]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
> ~[na:na]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
> ~[na:na]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70)
> ~[na:na]
> at
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1247)
> ~[na:na]
> at
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1243)
> ~[na:na]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_74]
> ... 2 common frames omitted
> {code}
> It looks like at some point we switched from using SchedulingContext to
> ProcessContext for methods annotated with @OnScheduled but somehow these
> processors were never updated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-1898) Flume Processors can not be started
[
https://issues.apache.org/jira/browse/NIFI-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Zhurakousky updated NIFI-1898:
---
Fix Version/s: 0.7.0
1.0.0
> Flume Processors can not be started
> ---
>
> Key: NIFI-1898
> URL: https://issues.apache.org/jira/browse/NIFI-1898
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 0.6.1
>Reporter: Bryan Bende
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0, 0.7.0
>
>
> When trying to use ExecuteFlumeSource, the following error was encountered:
> {code}
> 2016-05-18 14:06:14,338 ERROR [StandardProcessScheduler Thread-5]
> org.apache.nifi.util.ReflectionUtils Can not invoke method 'public void
> org.apache.nifi.processors.flume.ExecuteFlumeSource.onScheduled(org.apache.nifi.processor.SchedulingContext)'
> with provided arguments since argument 0 of type 'interface
> org.apache.nifi.processor.SchedulingContext' is not assignable from provided
> value of type 'class org.apache.nifi.processor.StandardProcessContext'.
> 2016-05-18 14:06:14,338 ERROR [StandardProcessScheduler Thread-2]
> o.a.n.p.flume.ExecuteFlumeSource
> ExecuteFlumeSource[id=df4a6e2d-be59-448a-857b-5e88df88052e]
> ExecuteFlumeSource[id=df4a6e2d-be59-448a-857b-5e88df88052e] failed to invoke
> @OnScheduled method due to java.lang.RuntimeException: Failed while executing
> one of processor's OnScheduled task.; processor will not be scheduled to run
> for 3 milliseconds: java.lang.RuntimeException: Failed while executing
> one of processor's OnScheduled task.
> 2016-05-18 14:06:14,340 ERROR [StandardProcessScheduler Thread-5]
> org.apache.nifi.engine.FlowEngine A flow controller task execution stopped
> abnormally
> java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException:
> argument type mismatch
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> ~[na:1.8.0_74]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> ~[na:1.8.0_74]
> at org.apache.nifi.engine.FlowEngine.afterExecute(FlowEngine.java:100)
> ~[na:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1150)
> [na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_74]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_74]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_74]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_74]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_74]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
> ~[na:na]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
> ~[na:na]
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70)
> ~[na:na]
> at
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1247)
> ~[na:na]
> at
> org.apache.nifi.controller.StandardProcessorNode$1$1.call(StandardProcessorNode.java:1243)
> ~[na:na]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ~[na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_74]
> ... 2 common frames omitted
> {code}
> It looks like at some point we switched from using SchedulingContext to
> ProcessContext for methods annotated with @OnScheduled but somehow these
> processors were never updated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
