[DISCUSS] NIFI-1069 / PR1093 - Return code for a NiFi not responding to ping

[Edgardo Vega]

I would say go with 4.

Ansible will see 1, 2, 3, 4, 69 as not running and do the correct thing.
Puppet sees 0 vs non zero. I think If he service is up running and
responding to pings return 0 anything else should return another code. This
will allow these tools to restart the application to get them back into a
good state.

Not sure what would put nifi into this state maybe disk full.

Cheers,

Edgardo


On Friday, October 14, 2016, Andre > wrote:

> devs,
>
> I am reviewing PR#1093, which happens to be a great contribution towards a
> LSB compliant NiFi (something the overall community seems to be eager to
> have).
>
> The PR basically changes RunNiFi.java so that it returns a numeric exit
> code compatible with the LSB specifications.
>
> I am happy with the overall code but there's one sticking point:
>
> Should we return 0 (i.e. "healthy") when "Apache NiFi is running at PID {}
> but is not responding to ping requests" ?
>
> The LSB defines:
>
> "
> If the status action is requested, the init script will return the
> following exit status codes.
>
> 0 program is running or service is OK
> 1 program is dead and /var/run pid file exists
> 2 program is dead and /var/lock lock file exists
> 3 program is not running
> 4 program or service status is unknown
> 5-99 reserved for future LSB use
> 100-149 reserved for distribution use
> 150-199 reserved for application use
> 200-254 reserved
> "
>
> My reading is that we should return 4, for the JVM PID is currently
> running, however, the absence of a ping response could signal the NiFi
> program running within the JVM is not healthy. (the PR contribution returns
> 0).
>
> Would anyone have a view on what usually would cause a NiFi instance to be
> "running" but unable to respond to pings? Whenever that happens should we
> return 0 (running/service ok) or 4 (program/service status unknown)?
>
> I thank you in advance
>


-- 
Cheers,

Edgardo

Sent from Gmail Mobile

Re: [DISCUSS] NIFI-1069 / PR1093 - Return code for a NiFi not responding to ping

[Mark Payne]

Andre,

In that case, I agree with you that a 4 would be the proper response. Things 
that I can
think of that may cause it not to respond:

1) Long Garbage Collection pause
2) Stuck in some sort of infinite loop or just way overtaxed CPU
3) Too many open files prevents it from accepting the connection

Not sure what else may cause this...

Thanks
-Mark

> On Oct 14, 2016, at 9:08 PM, Andre  wrote:
> 
> devs,
> 
> I am reviewing PR#1093, which happens to be a great contribution towards a
> LSB compliant NiFi (something the overall community seems to be eager to
> have).
> 
> The PR basically changes RunNiFi.java so that it returns a numeric exit
> code compatible with the LSB specifications.
> 
> I am happy with the overall code but there's one sticking point:
> 
> Should we return 0 (i.e. "healthy") when "Apache NiFi is running at PID {}
> but is not responding to ping requests" ?
> 
> The LSB defines:
> 
> "
> If the status action is requested, the init script will return the
> following exit status codes.
> 
> 0 program is running or service is OK
> 1 program is dead and /var/run pid file exists
> 2 program is dead and /var/lock lock file exists
> 3 program is not running
> 4 program or service status is unknown
> 5-99 reserved for future LSB use
> 100-149 reserved for distribution use
> 150-199 reserved for application use
> 200-254 reserved
> "
> 
> My reading is that we should return 4, for the JVM PID is currently
> running, however, the absence of a ping response could signal the NiFi
> program running within the JVM is not healthy. (the PR contribution returns
> 0).
> 
> Would anyone have a view on what usually would cause a NiFi instance to be
> "running" but unable to respond to pings? Whenever that happens should we
> return 0 (running/service ok) or 4 (program/service status unknown)?
> 
> I thank you in advance

[DISCUSS] NIFI-1069 / PR1093 - Return code for a NiFi not responding to ping

[Andre]

devs,

I am reviewing PR#1093, which happens to be a great contribution towards a
LSB compliant NiFi (something the overall community seems to be eager to
have).

The PR basically changes RunNiFi.java so that it returns a numeric exit
code compatible with the LSB specifications.

I am happy with the overall code but there's one sticking point:

Should we return 0 (i.e. "healthy") when "Apache NiFi is running at PID {}
but is not responding to ping requests" ?

The LSB defines:

"
If the status action is requested, the init script will return the
following exit status codes.

0 program is running or service is OK
1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists
3 program is not running
4 program or service status is unknown
5-99 reserved for future LSB use
100-149 reserved for distribution use
150-199 reserved for application use
200-254 reserved
"

My reading is that we should return 4, for the JVM PID is currently
running, however, the absence of a ping response could signal the NiFi
program running within the JVM is not healthy. (the PR contribution returns
0).

Would anyone have a view on what usually would cause a NiFi instance to be
"running" but unable to respond to pings? Whenever that happens should we
return 0 (running/service ok) or 4 (program/service status unknown)?

I thank you in advance

Re: Problem preparing to execute 0.7.1 release

[Tony Kurc]

Also, it looks like the difference between the KEYS file on dev and release
prior to you adding your key to dev is that it looks like Joe Percivall's
key was sort of added twice to the release repo.

dev KEYS before Joe Skora addition:
 https://dist.apache.org/repos/dist/dev/nifi/KEYS?p=14135

release KEYS now :
https://dist.apache.org/repos/dist/release/nifi/KEYS?p=14117

release KEYS before Joe Percivall addition (major difference is adding two
identical key blocks)
https://dist.apache.org/repos/dist/release/nifi/KEYS?p=14116

We should tidy that up when the next release is ready.


On Fri, Oct 14, 2016 at 2:10 PM, Joe Witt  wrote:

> I'm thinking the same thing Tony.  Joe you should be able to do the
> full process and we just might need to help with the final push of the
> official bits to the release directory.  In parallel please submit a
> request to INFRA on permissions for that folder.  Perhaps there is
> something else I need to activate though I'm not aware of anything.
>
> Thanks
> Joe
>
> On Fri, Oct 14, 2016 at 2:06 PM, Tony Kurc  wrote:
> > I think if you can't commit or move to dist/release, the last bit of the
> > release, (moving them over) won't work. I didn't have the issue you
> > mentioned with the KEYS file, but I think you mentioned to me out of band
> > the two files were different before you got started (
> > https://dist.apache.org/repos/dist/dev/nifi/KEYS vs
> > https://dist.apache.org/repos/dist/release/nifi/KEYS) . I'll investigate
> > that bit.
> >
> > I could be wrong, but if your key is in https://dist.apache.org/repos/
> > dist/dev/nifi/KEYS, then you would be able to put together the release
> > candidate even with the svn permission problems you're having, as that
> move
> > to dist/release comes only after the vote is successful.
> >
> > I also don't know what the permissions _should_ be for dist/release, I
> did
> > some cursory searching on the ASF docs to find something, but was not
> > successful.
> >
> > Tony
> >
> > On Fri, Oct 14, 2016 at 12:01 PM, Joe Skora  wrote:
> >
> >> I hit a problem working on the 0.7.1 release, I can't get my keys
> committed
> >> to the dist/release repository.
> >>
> >> I committed them to the dist/dev repo (
> >> https://dist.apache.org/repos/dist/dev/nifi/KEYS) but I cannot move the
> >> file to the dist/release repo or commit directly to it, both return "403
> >> forbidden" errors.
> >>
> >> Based on the NiFi Release Guidelines
> >>  I believe my keys need to
> be
> >> added before performing Maven release steps, so I'm stuck until I get
> this
> >> sorted out.
> >>
> >> I don't know if I'm doing something wrong or if there's a permission
> >> problem somewhere.  Should I be able to commit to dist/release?
> >>
> >> Has anyone had any problems like this in the past?
> >>
> >> Thanks for any help.  (I will be away from my computer until Saturday
> >> night, but will pick this back up Sunday.)
> >>
> >> Regards,
> >> Joe S
> >>
>

Re: [DISCUSS] NiFi 1.1.0 release

[Edgardo Vega]

Joe,

Appreciate the offer it isn't my PR. I was just using it as an example. All
mine are currently closed, which I greatly appreciate.

Cheers,

Edgardo

On Friday, October 14, 2016, Joe Witt  wrote:

> Edgardo,
>
> You mentioned a PR from August. I'd be happy to help you work that
> through review.
>
> Thanks
> Joe
>
> On Fri, Oct 14, 2016 at 10:45 AM, Edgardo Vega  > wrote:
> > I have agreed that at this point a release is important. My goal was try
> to
> > squeeze in a much goodness as possible into the release, but the
> important
> > bug fixes should come first. Getting 1.x into a state where the release
> > notes don't say that it is geared toward developers and testers is really
> > huge.
> >
> > I think Nifi is a great community otherwise I would participate in the
> > mailing list, create Jira tickets and pull requests. I am only trying to
> > strengthen the great thing that is going on here. We can always do
> better.
> > I was not trying to put down this community only to participate and make
> it
> > better. I think this conversation is an indication of how great this
> > community is.
> >
> > Maybe I am being sensitive about this issue and trying to strengthen the
> > nifi community even more, after coming from a conference where it was
> > reported there was lots of excitement at first and now the participation
> in
> > the community has really died down and they are struggling. I don't want
> to
> > see that happen here.
> >
> > Cheers,
> >
> > Edgardo
> >
> >
> >
> >
> > On Fri, Oct 14, 2016 at 9:37 AM, Andre  > wrote:
> >
> >> Edgardo,
> >>
> >> Thank you for your feedback. We hear your comments and as a committer I
> can
> >> share we are constantly looking to improve the PR process, having
> already
> >> taken many of the steps you suggest.
> >>
> >> However, it is important to notice that the number of PRs should not be
> >> seen as a metric of engagement by the development community: Most of us
> >> will submit PRs so that our work can be carefully reviewed by our peers
> and
> >> some of us will use JIRA patches to provide contributions.
> >>
> >> Having said that, it is true that some PRs may sit idle for a long time
> and
> >> we are working to improve this pipeline.
> >>
> >> It was therefore no coincidence that I  browsed most of the PRs
> performing
> >> a triage of items that have been superseded or diverged from the current
> >> code base.
> >>
> >> In fact, less than a month ago the dev team closed a number of stalled
> and
> >> superseded PRs (commit cc5e827aa1dfe2f376e9836380ba63c15269eea8).
> >>
> >> Despite all the above, I think Joe has a point. The master contain a
> series
> >> of important bug fixes and suspect the community would benefit from a
> >> release sooner rather than later.
> >>
> >> Once again, thank you for your feedback and contribution. It is good to
> >> have you here.
> >>
> >> Andre
> >>
> >> On Fri, Oct 14, 2016 at 11:30 PM, Edgardo Vega  >
> >> wrote:
> >>
> >> > Joe - You are correct I was mentioning the PRs that are currently
> open.
> >> >
> >> > Regardless of how it happens reducing the count of open PRs I believe
> to
> >> be
> >> > extremely important. Maybe I was hoping that the release could be a
> >> forcing
> >> > function to make that happen. I believe that developers are more
> willing
> >> to
> >> > contribute when they see that their PRs will actually be able accepted
> >> and
> >> > merged into the code base. Having a low number of open PRs in progress
> >> is a
> >> > great indication that the main nifi developers are fully engaged with
> the
> >> > community.
> >> >
> >> > There are a few PRs that don't have any comments from committers at
> all.
> >> I
> >> > found one from August in that state. If that was my PR I don't think I
> >> > would be so willing to put another one in anytime soon. I do get that
> >> > sometime PRs get stalled by the originator, if so maybe a rule about
> >> > closing them after a certain amount of time or being taken over by a
> core
> >> > contributor if they think it worthwhile.
> >> >
> >> > I would like to shoutout to James Wing on my last PR he was quick to
> >> > review, provided great comments, testing, and even some additional
> code.
> >> It
> >> > was a great PR experience.
> >> >
> >> > Cheers,
> >> >
> >> > Edgardo
> >> >
> >> >
> >> >
> >> > On Thu, Oct 13, 2016 at 4:14 PM, Joe Percivall <
> joeperciv...@yahoo.com .
> >> > invalid> wrote:
> >> >
> >> > > Joe, I think you misread. Edgardo is referring to the Pull Requests
> >> that
> >> > > are currently open, not the tickets assigned to the 1.1.0 version.
> >> > >
> >> > > I think these goals (releasing 1.1.0 and cutting down the PR count)
> >> > should
> >> > > be two different efforts. Doing a thorough job reviewing takes a
> >> > > significant amount of time from both the reviewer and 

Re: Problem preparing to execute 0.7.1 release

[Joe Witt]

I'm thinking the same thing Tony.  Joe you should be able to do the
full process and we just might need to help with the final push of the
official bits to the release directory.  In parallel please submit a
request to INFRA on permissions for that folder.  Perhaps there is
something else I need to activate though I'm not aware of anything.

Thanks
Joe

On Fri, Oct 14, 2016 at 2:06 PM, Tony Kurc  wrote:
> I think if you can't commit or move to dist/release, the last bit of the
> release, (moving them over) won't work. I didn't have the issue you
> mentioned with the KEYS file, but I think you mentioned to me out of band
> the two files were different before you got started (
> https://dist.apache.org/repos/dist/dev/nifi/KEYS vs
> https://dist.apache.org/repos/dist/release/nifi/KEYS) . I'll investigate
> that bit.
>
> I could be wrong, but if your key is in https://dist.apache.org/repos/
> dist/dev/nifi/KEYS, then you would be able to put together the release
> candidate even with the svn permission problems you're having, as that move
> to dist/release comes only after the vote is successful.
>
> I also don't know what the permissions _should_ be for dist/release, I did
> some cursory searching on the ASF docs to find something, but was not
> successful.
>
> Tony
>
> On Fri, Oct 14, 2016 at 12:01 PM, Joe Skora  wrote:
>
>> I hit a problem working on the 0.7.1 release, I can't get my keys committed
>> to the dist/release repository.
>>
>> I committed them to the dist/dev repo (
>> https://dist.apache.org/repos/dist/dev/nifi/KEYS) but I cannot move the
>> file to the dist/release repo or commit directly to it, both return "403
>> forbidden" errors.
>>
>> Based on the NiFi Release Guidelines
>>  I believe my keys need to be
>> added before performing Maven release steps, so I'm stuck until I get this
>> sorted out.
>>
>> I don't know if I'm doing something wrong or if there's a permission
>> problem somewhere.  Should I be able to commit to dist/release?
>>
>> Has anyone had any problems like this in the past?
>>
>> Thanks for any help.  (I will be away from my computer until Saturday
>> night, but will pick this back up Sunday.)
>>
>> Regards,
>> Joe S
>>

Re: Problem preparing to execute 0.7.1 release

[Tony Kurc]

I think if you can't commit or move to dist/release, the last bit of the
release, (moving them over) won't work. I didn't have the issue you
mentioned with the KEYS file, but I think you mentioned to me out of band
the two files were different before you got started (
https://dist.apache.org/repos/dist/dev/nifi/KEYS vs
https://dist.apache.org/repos/dist/release/nifi/KEYS) . I'll investigate
that bit.

I could be wrong, but if your key is in https://dist.apache.org/repos/
dist/dev/nifi/KEYS, then you would be able to put together the release
candidate even with the svn permission problems you're having, as that move
to dist/release comes only after the vote is successful.

I also don't know what the permissions _should_ be for dist/release, I did
some cursory searching on the ASF docs to find something, but was not
successful.

Tony

On Fri, Oct 14, 2016 at 12:01 PM, Joe Skora  wrote:

> I hit a problem working on the 0.7.1 release, I can't get my keys committed
> to the dist/release repository.
>
> I committed them to the dist/dev repo (
> https://dist.apache.org/repos/dist/dev/nifi/KEYS) but I cannot move the
> file to the dist/release repo or commit directly to it, both return "403
> forbidden" errors.
>
> Based on the NiFi Release Guidelines
>  I believe my keys need to be
> added before performing Maven release steps, so I'm stuck until I get this
> sorted out.
>
> I don't know if I'm doing something wrong or if there's a permission
> problem somewhere.  Should I be able to commit to dist/release?
>
> Has anyone had any problems like this in the past?
>
> Thanks for any help.  (I will be away from my computer until Saturday
> night, but will pick this back up Sunday.)
>
> Regards,
> Joe S
>

Re: [DISCUSS] NiFi 1.1.0 release

[Joe Witt]

Edgardo,

You mentioned a PR from August. I'd be happy to help you work that
through review.

Thanks
Joe

On Fri, Oct 14, 2016 at 10:45 AM, Edgardo Vega  wrote:
> I have agreed that at this point a release is important. My goal was try to
> squeeze in a much goodness as possible into the release, but the important
> bug fixes should come first. Getting 1.x into a state where the release
> notes don't say that it is geared toward developers and testers is really
> huge.
>
> I think Nifi is a great community otherwise I would participate in the
> mailing list, create Jira tickets and pull requests. I am only trying to
> strengthen the great thing that is going on here. We can always do better.
> I was not trying to put down this community only to participate and make it
> better. I think this conversation is an indication of how great this
> community is.
>
> Maybe I am being sensitive about this issue and trying to strengthen the
> nifi community even more, after coming from a conference where it was
> reported there was lots of excitement at first and now the participation in
> the community has really died down and they are struggling. I don't want to
> see that happen here.
>
> Cheers,
>
> Edgardo
>
>
>
>
> On Fri, Oct 14, 2016 at 9:37 AM, Andre  wrote:
>
>> Edgardo,
>>
>> Thank you for your feedback. We hear your comments and as a committer I can
>> share we are constantly looking to improve the PR process, having already
>> taken many of the steps you suggest.
>>
>> However, it is important to notice that the number of PRs should not be
>> seen as a metric of engagement by the development community: Most of us
>> will submit PRs so that our work can be carefully reviewed by our peers and
>> some of us will use JIRA patches to provide contributions.
>>
>> Having said that, it is true that some PRs may sit idle for a long time and
>> we are working to improve this pipeline.
>>
>> It was therefore no coincidence that I  browsed most of the PRs performing
>> a triage of items that have been superseded or diverged from the current
>> code base.
>>
>> In fact, less than a month ago the dev team closed a number of stalled and
>> superseded PRs (commit cc5e827aa1dfe2f376e9836380ba63c15269eea8).
>>
>> Despite all the above, I think Joe has a point. The master contain a series
>> of important bug fixes and suspect the community would benefit from a
>> release sooner rather than later.
>>
>> Once again, thank you for your feedback and contribution. It is good to
>> have you here.
>>
>> Andre
>>
>> On Fri, Oct 14, 2016 at 11:30 PM, Edgardo Vega 
>> wrote:
>>
>> > Joe - You are correct I was mentioning the PRs that are currently open.
>> >
>> > Regardless of how it happens reducing the count of open PRs I believe to
>> be
>> > extremely important. Maybe I was hoping that the release could be a
>> forcing
>> > function to make that happen. I believe that developers are more willing
>> to
>> > contribute when they see that their PRs will actually be able accepted
>> and
>> > merged into the code base. Having a low number of open PRs in progress
>> is a
>> > great indication that the main nifi developers are fully engaged with the
>> > community.
>> >
>> > There are a few PRs that don't have any comments from committers at all.
>> I
>> > found one from August in that state. If that was my PR I don't think I
>> > would be so willing to put another one in anytime soon. I do get that
>> > sometime PRs get stalled by the originator, if so maybe a rule about
>> > closing them after a certain amount of time or being taken over by a core
>> > contributor if they think it worthwhile.
>> >
>> > I would like to shoutout to James Wing on my last PR he was quick to
>> > review, provided great comments, testing, and even some additional code.
>> It
>> > was a great PR experience.
>> >
>> > Cheers,
>> >
>> > Edgardo
>> >
>> >
>> >
>> > On Thu, Oct 13, 2016 at 4:14 PM, Joe Percivall > > invalid> wrote:
>> >
>> > > Joe, I think you misread. Edgardo is referring to the Pull Requests
>> that
>> > > are currently open, not the tickets assigned to the 1.1.0 version.
>> > >
>> > > I think these goals (releasing 1.1.0 and cutting down the PR count)
>> > should
>> > > be two different efforts. Doing a thorough job reviewing takes a
>> > > significant amount of time from both the reviewer and contributor. In
>> > order
>> > > to cut it down significantly would take much longer than a couple days.
>> > >
>> > > Also there has already been a lot of great new features and bug fixes
>> > > contributed to the 1.X line and I don't think it's worth holding up a
>> > 1.1.0
>> > > release for tickets not assigned to this fix version. As an added bonus
>> > > though, I think many of the tickets tagged as 1.1.0 have PRs already
>> open
>> > > so closing those will make a large dent in the PR count.
>> > >
>> > >
>> > > Joe
>> > >
>> > > - - - - - -
>> > > 

Re: InvokeHTTP - no relationship invoked for 502 response

[Jeremy Dyer]

Matt - Your right about just adding a "RouteOnAttribute" processor. I got
so caught up in trying to understand why a retry wasn't getting fired I
lost track of my original goal. I think I have a understanding of why the
"retry" was not getting fired now and that makes perfect sense. I will just
add the "RouteOnAttribute" processor now to check for a 200 or 502 code in
the response.

Thanks

On Fri, Oct 14, 2016 at 12:50 PM, Matt Burgess  wrote:

> This might be intended behavior, it appears that only request
> (incoming) flow files get routed to relationships like "retry", but
> you have no incoming request flow file so there is technically nothing
> to retry (the processor will "retry" the next time it runs). In your
> case it sounds like you'd need a RouteOnAttribute for the "response"
> relationship in order to handle responses when there was no request
> flow file.
>
> Alternatively, what would you expect the behavior to be? Would
> responses and requests (if present) be routed to "retry", or would a
> "fake" request be generated for a GET with no incoming flow file? In
> the former case you'd have two types of flow files to deal with (is it
> request or response?), in the latter case the flow file would likely
> only be an indication that a GET occurred, as it would have no
> content, and if the retry route were connected back to InvokeHttp, it
> seems functionally the same as the InvokeHttp running on its own
> schedule (it would try the GET again later when scheduled).  Not
> saying either is necessarily bad, just wanted to get your thoughts.
>
> Thanks,
> Matt
>
> On Fri, Oct 14, 2016 at 12:29 PM, Jeremy Dyer  wrote:
> > Matt - No, I am not seeing this expected behavior. Nothing is being
> routed
> > to "retry" as expected. IF I set "Always Output Response" = true the
> > "Response" relationship is triggered and even in there you can see the
> > "invoke.http.statuscode=502" I have attached a screenshot to show you
> what I
> > mean. Looking at the code the only possible explanation for this would be
> > that the incoming flowfile == null. Since my "InvokeHTTP" is a simple
> "GET"
> > with no incoming flowfile I believe that the line at [1] is not being
> > invoked as expected because the property at [2] is not set. However I do
> not
> > want to set that property.
> >
> > [1]
> > https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L596
> > [2]
> > https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L586
> >
> > On Fri, Oct 14, 2016 at 12:11 PM, Matt Burgess 
> wrote:
> >>
> >> Jeremy,
> >>
> >> The code implies that 502 responses (actually all 5xx responses) are
> >> routed to "retry" [1]. Are you not seeing that?
> >>
> >> Regards,
> >> Matt
> >>
> >> [1]
> >> https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L906
> >>
> >> On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer  wrote:
> >> > I'm monitoring some micro services that sit behind an Nginx reverse
> >> > proxy.
> >> > The idea is simple I want to fire off an alert if I get a "502 - Bad
> >> > Gateway" response from Nginx which would mean that something has
> caused
> >> > the
> >> > micro service to crash and then have NiFi attempt to restart the micro
> >> > service.
> >> >
> >> > However no relationship is being invoked when a 502 response code is
> >> > returned? Works great for 200 or even 500 but not getting any output
> >> > what
> >> > so ever for a 502? Any ideas?
> >> >
> >> > Thanks,
> >> > Jeremy Dyer
> >
> >
>

Re: InvokeHTTP - no relationship invoked for 502 response

[Matt Burgess]

This might be intended behavior, it appears that only request
(incoming) flow files get routed to relationships like "retry", but
you have no incoming request flow file so there is technically nothing
to retry (the processor will "retry" the next time it runs). In your
case it sounds like you'd need a RouteOnAttribute for the "response"
relationship in order to handle responses when there was no request
flow file.

Alternatively, what would you expect the behavior to be? Would
responses and requests (if present) be routed to "retry", or would a
"fake" request be generated for a GET with no incoming flow file? In
the former case you'd have two types of flow files to deal with (is it
request or response?), in the latter case the flow file would likely
only be an indication that a GET occurred, as it would have no
content, and if the retry route were connected back to InvokeHttp, it
seems functionally the same as the InvokeHttp running on its own
schedule (it would try the GET again later when scheduled).  Not
saying either is necessarily bad, just wanted to get your thoughts.

Thanks,
Matt

On Fri, Oct 14, 2016 at 12:29 PM, Jeremy Dyer  wrote:
> Matt - No, I am not seeing this expected behavior. Nothing is being routed
> to "retry" as expected. IF I set "Always Output Response" = true the
> "Response" relationship is triggered and even in there you can see the
> "invoke.http.statuscode=502" I have attached a screenshot to show you what I
> mean. Looking at the code the only possible explanation for this would be
> that the incoming flowfile == null. Since my "InvokeHTTP" is a simple "GET"
> with no incoming flowfile I believe that the line at [1] is not being
> invoked as expected because the property at [2] is not set. However I do not
> want to set that property.
>
> [1]
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L596
> [2]
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L586
>
> On Fri, Oct 14, 2016 at 12:11 PM, Matt Burgess  wrote:
>>
>> Jeremy,
>>
>> The code implies that 502 responses (actually all 5xx responses) are
>> routed to "retry" [1]. Are you not seeing that?
>>
>> Regards,
>> Matt
>>
>> [1]
>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L906
>>
>> On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer  wrote:
>> > I'm monitoring some micro services that sit behind an Nginx reverse
>> > proxy.
>> > The idea is simple I want to fire off an alert if I get a "502 - Bad
>> > Gateway" response from Nginx which would mean that something has caused
>> > the
>> > micro service to crash and then have NiFi attempt to restart the micro
>> > service.
>> >
>> > However no relationship is being invoked when a 502 response code is
>> > returned? Works great for 200 or even 500 but not getting any output
>> > what
>> > so ever for a 502? Any ideas?
>> >
>> > Thanks,
>> > Jeremy Dyer
>
>

Re: InvokeHTTP - no relationship invoked for 502 response

[Jeremy Dyer]

Matt - No, I am not seeing this expected behavior. Nothing is being routed
to "retry" as expected. IF I set "Always Output Response" = true the
"Response" relationship is triggered and even in there you can see the
"invoke.http.statuscode=502" I have attached a screenshot to show you what
I mean. Looking at the code the only possible explanation for this would be
that the incoming flowfile == null. Since my "InvokeHTTP" is a simple "GET"
with no incoming flowfile I believe that the line at [1] is not being
invoked as expected because the property at [2] is not set. However I do
not want to set that property.

[1]
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L596
[2]
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L586

On Fri, Oct 14, 2016 at 12:11 PM, Matt Burgess  wrote:

> Jeremy,
>
> The code implies that 502 responses (actually all 5xx responses) are
> routed to "retry" [1]. Are you not seeing that?
>
> Regards,
> Matt
>
> [1] https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L906
>
> On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer  wrote:
> > I'm monitoring some micro services that sit behind an Nginx reverse
> proxy.
> > The idea is simple I want to fire off an alert if I get a "502 - Bad
> > Gateway" response from Nginx which would mean that something has caused
> the
> > micro service to crash and then have NiFi attempt to restart the micro
> > service.
> >
> > However no relationship is being invoked when a 502 response code is
> > returned? Works great for 200 or even 500 but not getting any output what
> > so ever for a 502? Any ideas?
> >
> > Thanks,
> > Jeremy Dyer
>

Re: InvokeHTTP - no relationship invoked for 502 response

[Matt Burgess]

Jeremy,

The code implies that 502 responses (actually all 5xx responses) are
routed to "retry" [1]. Are you not seeing that?

Regards,
Matt

[1] 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L906

On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer  wrote:
> I'm monitoring some micro services that sit behind an Nginx reverse proxy.
> The idea is simple I want to fire off an alert if I get a "502 - Bad
> Gateway" response from Nginx which would mean that something has caused the
> micro service to crash and then have NiFi attempt to restart the micro
> service.
>
> However no relationship is being invoked when a 502 response code is
> returned? Works great for 200 or even 500 but not getting any output what
> so ever for a 502? Any ideas?
>
> Thanks,
> Jeremy Dyer

Re: Issue on creating Custom Processor - Salesforce

[Jeremy Dyer]

Shankhamajumdar - I'd be glad to help you out but how about you email me
personally outside of this thread since this project isn't formally part of
the Apache community. Look forward to hearing from you

On Fri, Oct 14, 2016 at 8:29 AM, shankhamajumdar <
shankha.majum...@lexmark.com> wrote:

> Hi Jeremy,
>
> There is one more issue. Actually I did the build inside
> D:\nifi-addons-master\Services\nifi-salesforce-
> service\nifi-salesforce-api-nar
> directory successfully. But ideally I should build inside
> D:\nifi-addons-master\Services directory which is failing.
>
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Child module D:\nifi-addons-master\Services\nifi-google-auth-
> service
> of
> D:\nifi-addons-master\Services\pom.xml does not exist @
>  @
>
> I do not see nifi-google-auth-service as well in the
> D:\nifi-addons-master\Services directory.
>
> Regards,
> Shankha
>
>
>
>
>
> --
> View this message in context: http://apache-nifi-developer-
> list.39713.n7.nabble.com/Issue-on-creating-Custom-Processor-Salesforce-
> tp13603p13610.html
> Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>

Problem preparing to execute 0.7.1 release

[Joe Skora]

I hit a problem working on the 0.7.1 release, I can't get my keys committed
to the dist/release repository.

I committed them to the dist/dev repo (
https://dist.apache.org/repos/dist/dev/nifi/KEYS) but I cannot move the
file to the dist/release repo or commit directly to it, both return "403
forbidden" errors.

Based on the NiFi Release Guidelines
 I believe my keys need to be
added before performing Maven release steps, so I'm stuck until I get this
sorted out.

I don't know if I'm doing something wrong or if there's a permission
problem somewhere.  Should I be able to commit to dist/release?

Has anyone had any problems like this in the past?

Thanks for any help.  (I will be away from my computer until Saturday
night, but will pick this back up Sunday.)

Regards,
Joe S

InvokeHTTP - no relationship invoked for 502 response

[Jeremy Dyer]

I'm monitoring some micro services that sit behind an Nginx reverse proxy.
The idea is simple I want to fire off an alert if I get a "502 - Bad
Gateway" response from Nginx which would mean that something has caused the
micro service to crash and then have NiFi attempt to restart the micro
service.

However no relationship is being invoked when a 502 response code is
returned? Works great for 200 or even 500 but not getting any output what
so ever for a 502? Any ideas?

Thanks,
Jeremy Dyer

Re: [DISCUSS] NiFi 1.1.0 release

[Edgardo Vega]

I have agreed that at this point a release is important. My goal was try to
squeeze in a much goodness as possible into the release, but the important
bug fixes should come first. Getting 1.x into a state where the release
notes don't say that it is geared toward developers and testers is really
huge.

I think Nifi is a great community otherwise I would participate in the
mailing list, create Jira tickets and pull requests. I am only trying to
strengthen the great thing that is going on here. We can always do better.
I was not trying to put down this community only to participate and make it
better. I think this conversation is an indication of how great this
community is.

Maybe I am being sensitive about this issue and trying to strengthen the
nifi community even more, after coming from a conference where it was
reported there was lots of excitement at first and now the participation in
the community has really died down and they are struggling. I don't want to
see that happen here.

Cheers,

Edgardo




On Fri, Oct 14, 2016 at 9:37 AM, Andre  wrote:

> Edgardo,
>
> Thank you for your feedback. We hear your comments and as a committer I can
> share we are constantly looking to improve the PR process, having already
> taken many of the steps you suggest.
>
> However, it is important to notice that the number of PRs should not be
> seen as a metric of engagement by the development community: Most of us
> will submit PRs so that our work can be carefully reviewed by our peers and
> some of us will use JIRA patches to provide contributions.
>
> Having said that, it is true that some PRs may sit idle for a long time and
> we are working to improve this pipeline.
>
> It was therefore no coincidence that I  browsed most of the PRs performing
> a triage of items that have been superseded or diverged from the current
> code base.
>
> In fact, less than a month ago the dev team closed a number of stalled and
> superseded PRs (commit cc5e827aa1dfe2f376e9836380ba63c15269eea8).
>
> Despite all the above, I think Joe has a point. The master contain a series
> of important bug fixes and suspect the community would benefit from a
> release sooner rather than later.
>
> Once again, thank you for your feedback and contribution. It is good to
> have you here.
>
> Andre
>
> On Fri, Oct 14, 2016 at 11:30 PM, Edgardo Vega 
> wrote:
>
> > Joe - You are correct I was mentioning the PRs that are currently open.
> >
> > Regardless of how it happens reducing the count of open PRs I believe to
> be
> > extremely important. Maybe I was hoping that the release could be a
> forcing
> > function to make that happen. I believe that developers are more willing
> to
> > contribute when they see that their PRs will actually be able accepted
> and
> > merged into the code base. Having a low number of open PRs in progress
> is a
> > great indication that the main nifi developers are fully engaged with the
> > community.
> >
> > There are a few PRs that don't have any comments from committers at all.
> I
> > found one from August in that state. If that was my PR I don't think I
> > would be so willing to put another one in anytime soon. I do get that
> > sometime PRs get stalled by the originator, if so maybe a rule about
> > closing them after a certain amount of time or being taken over by a core
> > contributor if they think it worthwhile.
> >
> > I would like to shoutout to James Wing on my last PR he was quick to
> > review, provided great comments, testing, and even some additional code.
> It
> > was a great PR experience.
> >
> > Cheers,
> >
> > Edgardo
> >
> >
> >
> > On Thu, Oct 13, 2016 at 4:14 PM, Joe Percivall  > invalid> wrote:
> >
> > > Joe, I think you misread. Edgardo is referring to the Pull Requests
> that
> > > are currently open, not the tickets assigned to the 1.1.0 version.
> > >
> > > I think these goals (releasing 1.1.0 and cutting down the PR count)
> > should
> > > be two different efforts. Doing a thorough job reviewing takes a
> > > significant amount of time from both the reviewer and contributor. In
> > order
> > > to cut it down significantly would take much longer than a couple days.
> > >
> > > Also there has already been a lot of great new features and bug fixes
> > > contributed to the 1.X line and I don't think it's worth holding up a
> > 1.1.0
> > > release for tickets not assigned to this fix version. As an added bonus
> > > though, I think many of the tickets tagged as 1.1.0 have PRs already
> open
> > > so closing those will make a large dent in the PR count.
> > >
> > >
> > > Joe
> > >
> > > - - - - - -
> > > Joseph Percivall
> > > linkedin.com/in/Percivall
> > > e: joeperciv...@yahoo.com
> > >
> > >
> > >
> > > On Thursday, October 13, 2016 3:58 PM, Joe Witt 
> > > wrote:
> > >
> > >
> > >
> > > There are less than 30 right now.  Many of the roughly 90+ JIRAs
> > > opened on 1.1.0 were easily dispositioned to 

Re: Issue on creating Custom Processor - Salesforce

[shankhamajumdar]

Hi Jeremy,

There is one more issue. Actually I did the build inside
D:\nifi-addons-master\Services\nifi-salesforce-service\nifi-salesforce-api-nar
directory successfully. But ideally I should build inside
D:\nifi-addons-master\Services directory which is failing.

[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Child module D:\nifi-addons-master\Services\nifi-google-auth-service
of
D:\nifi-addons-master\Services\pom.xml does not exist @
 @

I do not see nifi-google-auth-service as well in the
D:\nifi-addons-master\Services directory.

Regards,
Shankha





--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Issue-on-creating-Custom-Processor-Salesforce-tp13603p13610.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: [DISCUSS] NiFi 1.1.0 release

[Andre]

Edgardo,

Thank you for your feedback. We hear your comments and as a committer I can
share we are constantly looking to improve the PR process, having already
taken many of the steps you suggest.

However, it is important to notice that the number of PRs should not be
seen as a metric of engagement by the development community: Most of us
will submit PRs so that our work can be carefully reviewed by our peers and
some of us will use JIRA patches to provide contributions.

Having said that, it is true that some PRs may sit idle for a long time and
we are working to improve this pipeline.

It was therefore no coincidence that I  browsed most of the PRs performing
a triage of items that have been superseded or diverged from the current
code base.

In fact, less than a month ago the dev team closed a number of stalled and
superseded PRs (commit cc5e827aa1dfe2f376e9836380ba63c15269eea8).

Despite all the above, I think Joe has a point. The master contain a series
of important bug fixes and suspect the community would benefit from a
release sooner rather than later.

Once again, thank you for your feedback and contribution. It is good to
have you here.

Andre

On Fri, Oct 14, 2016 at 11:30 PM, Edgardo Vega 
wrote:

> Joe - You are correct I was mentioning the PRs that are currently open.
>
> Regardless of how it happens reducing the count of open PRs I believe to be
> extremely important. Maybe I was hoping that the release could be a forcing
> function to make that happen. I believe that developers are more willing to
> contribute when they see that their PRs will actually be able accepted and
> merged into the code base. Having a low number of open PRs in progress is a
> great indication that the main nifi developers are fully engaged with the
> community.
>
> There are a few PRs that don't have any comments from committers at all. I
> found one from August in that state. If that was my PR I don't think I
> would be so willing to put another one in anytime soon. I do get that
> sometime PRs get stalled by the originator, if so maybe a rule about
> closing them after a certain amount of time or being taken over by a core
> contributor if they think it worthwhile.
>
> I would like to shoutout to James Wing on my last PR he was quick to
> review, provided great comments, testing, and even some additional code. It
> was a great PR experience.
>
> Cheers,
>
> Edgardo
>
>
>
> On Thu, Oct 13, 2016 at 4:14 PM, Joe Percivall  invalid> wrote:
>
> > Joe, I think you misread. Edgardo is referring to the Pull Requests that
> > are currently open, not the tickets assigned to the 1.1.0 version.
> >
> > I think these goals (releasing 1.1.0 and cutting down the PR count)
> should
> > be two different efforts. Doing a thorough job reviewing takes a
> > significant amount of time from both the reviewer and contributor. In
> order
> > to cut it down significantly would take much longer than a couple days.
> >
> > Also there has already been a lot of great new features and bug fixes
> > contributed to the 1.X line and I don't think it's worth holding up a
> 1.1.0
> > release for tickets not assigned to this fix version. As an added bonus
> > though, I think many of the tickets tagged as 1.1.0 have PRs already open
> > so closing those will make a large dent in the PR count.
> >
> >
> > Joe
> >
> > - - - - - -
> > Joseph Percivall
> > linkedin.com/in/Percivall
> > e: joeperciv...@yahoo.com
> >
> >
> >
> > On Thursday, October 13, 2016 3:58 PM, Joe Witt 
> > wrote:
> >
> >
> >
> > There are less than 30 right now.  Many of the roughly 90+ JIRAs
> > opened on 1.1.0 were easily dispositioned to 1.2.0 or closed or just
> > had fix versions removed.
> >
> > We will need to have a push over the next bunch of days to deal with
> > reviewing/merging/moving the remaining items.
> >
> > Thanks
> > Joe
> >
> >
> > On Thu, Oct 13, 2016 at 3:49 PM, Edgardo Vega 
> > wrote:
> > > Joe,
> > >
> > > There are 75 PRs currently open. Why not make a push over the next
> bunch
> > of
> > > days to get them closed and then cut the release after that.
> > >
> > > Cheers,
> > >
> > > Edgardo
> > >
> > > On Thu, Oct 13, 2016 at 12:44 PM, Joe Witt  wrote:
> > >
> > >> Team,
> > >>
> > >> There have been a ton of bugs fixed a few nice features.  I would like
> > >> to move to get Apache NiFi 1.1.0 release going pretty much based on
> > >> where we are now and plan to move most tickets to a new Apache NiFi
> > >> 1.2.0 version.  We can try to get back on our roughly 6-8 week release
> > >> schedule and shoot for a mid to late Nov release for NiFi 1.2.0 this
> > >> way as well. Please advise if anyone has any other views on this. In
> > >> the mean time I'll get the wheels in motion so you'll be seeing a lot
> > >> of JIRA/issue updates to move version around.
> > >>
> > >> Thanks
> > >> Joe
> > >>
> > >> On Thu, Oct 13, 2016 at 12:02 PM, Tony 

Re: [DISCUSS] NiFi 1.1.0 release

[Edgardo Vega]

Joe - You are correct I was mentioning the PRs that are currently open.

Regardless of how it happens reducing the count of open PRs I believe to be
extremely important. Maybe I was hoping that the release could be a forcing
function to make that happen. I believe that developers are more willing to
contribute when they see that their PRs will actually be able accepted and
merged into the code base. Having a low number of open PRs in progress is a
great indication that the main nifi developers are fully engaged with the
community.

There are a few PRs that don't have any comments from committers at all. I
found one from August in that state. If that was my PR I don't think I
would be so willing to put another one in anytime soon. I do get that
sometime PRs get stalled by the originator, if so maybe a rule about
closing them after a certain amount of time or being taken over by a core
contributor if they think it worthwhile.

I would like to shoutout to James Wing on my last PR he was quick to
review, provided great comments, testing, and even some additional code. It
was a great PR experience.

Cheers,

Edgardo



On Thu, Oct 13, 2016 at 4:14 PM, Joe Percivall  wrote:

> Joe, I think you misread. Edgardo is referring to the Pull Requests that
> are currently open, not the tickets assigned to the 1.1.0 version.
>
> I think these goals (releasing 1.1.0 and cutting down the PR count) should
> be two different efforts. Doing a thorough job reviewing takes a
> significant amount of time from both the reviewer and contributor. In order
> to cut it down significantly would take much longer than a couple days.
>
> Also there has already been a lot of great new features and bug fixes
> contributed to the 1.X line and I don't think it's worth holding up a 1.1.0
> release for tickets not assigned to this fix version. As an added bonus
> though, I think many of the tickets tagged as 1.1.0 have PRs already open
> so closing those will make a large dent in the PR count.
>
>
> Joe
>
> - - - - - -
> Joseph Percivall
> linkedin.com/in/Percivall
> e: joeperciv...@yahoo.com
>
>
>
> On Thursday, October 13, 2016 3:58 PM, Joe Witt 
> wrote:
>
>
>
> There are less than 30 right now.  Many of the roughly 90+ JIRAs
> opened on 1.1.0 were easily dispositioned to 1.2.0 or closed or just
> had fix versions removed.
>
> We will need to have a push over the next bunch of days to deal with
> reviewing/merging/moving the remaining items.
>
> Thanks
> Joe
>
>
> On Thu, Oct 13, 2016 at 3:49 PM, Edgardo Vega 
> wrote:
> > Joe,
> >
> > There are 75 PRs currently open. Why not make a push over the next bunch
> of
> > days to get them closed and then cut the release after that.
> >
> > Cheers,
> >
> > Edgardo
> >
> > On Thu, Oct 13, 2016 at 12:44 PM, Joe Witt  wrote:
> >
> >> Team,
> >>
> >> There have been a ton of bugs fixed a few nice features.  I would like
> >> to move to get Apache NiFi 1.1.0 release going pretty much based on
> >> where we are now and plan to move most tickets to a new Apache NiFi
> >> 1.2.0 version.  We can try to get back on our roughly 6-8 week release
> >> schedule and shoot for a mid to late Nov release for NiFi 1.2.0 this
> >> way as well. Please advise if anyone has any other views on this. In
> >> the mean time I'll get the wheels in motion so you'll be seeing a lot
> >> of JIRA/issue updates to move version around.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Thu, Oct 13, 2016 at 12:02 PM, Tony Kurc  wrote:
> >> > Sounds good Joe. I have no issue to you doing the rm'ing for it.
> >> >
> >> > On Oct 13, 2016 8:19 AM, "Joe Witt"  wrote:
> >> >
> >> >> Team,
> >> >>
> >> >> There are a lot of great fixes and improvements on the master line
> now
> >> >> and we're at a good time window to start pushing for a release.
> There
> >> >> are, however, about 90+ JIRAs assigned to 1.1.0 which are open.  I'm
> >> >> going to go through them and remove fix versions where appropriate.
> >> >>
> >> >> I'm happy to take on RM task for this release though if someone else
> >> >> would like to take that on please advise.
> >> >>
> >> >> Thanks
> >> >> Joe
> >> >>
> >>
> >
> >
> >
> > --
> > Cheers,
> >
> > Edgardo
>



-- 
Cheers,

Edgardo

Re: Issue on creating Custom Processor - Salesforce

[shankhamajumdar]

Thanks Jeremy, now the build is successful.

Regards,
Shankha



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Issue-on-creating-Custom-Processor-Salesforce-tp13603p13605.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Issue on creating Custom Processor - Salesforce

[Jeremy Dyer]

Shankhamajumdar - You are seeing this because the Salesforce controller 
services haven't been built yet. If you navigate to the {nifi_addons}/services 
directory and run a mvn clean install and then reattempt to build the 
processors the error should go away. 

- Jeremy Dyer

> On Oct 14, 2016, at 2:03 AM, shankhamajumdar  
> wrote:
> 
> Hi,
> 
> I am trying to create the Custom Salesforce Processor for Nifi but getting
> the below error while doing the maven build.
> 
> [ERROR] Failed to execute goal on project nifi-salesforce-processors: Could
> not
> resolve dependencies for project
> com.jeremydyer.nifi:nifi-salesforce-processors:
> jar:1.0.0: Could not find artifact
> com.jeremydyer.nifi:nifi-salesforce-api:jar:1
> .0.0 in central (https://repo1.maven.org/maven2) -> [Help 1]
> 
> The maven build for other Custom Processors are working fine.
> 
> Regards,
> Shankha
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/Issue-on-creating-Custom-Processor-Salesforce-tp13603.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Issue on creating Custom Processor - Salesforce

[shankhamajumdar]

Hi,

I am trying to create the Custom Salesforce Processor for Nifi but getting
the below error while doing the maven build.

[ERROR] Failed to execute goal on project nifi-salesforce-processors: Could
not
resolve dependencies for project
com.jeremydyer.nifi:nifi-salesforce-processors:
jar:1.0.0: Could not find artifact
com.jeremydyer.nifi:nifi-salesforce-api:jar:1
.0.0 in central (https://repo1.maven.org/maven2) -> [Help 1]

The maven build for other Custom Processors are working fine.

Regards,
Shankha





--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Issue-on-creating-Custom-Processor-Salesforce-tp13603.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.