[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue

[Koji Kawamura (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136142#comment-16136142
 ] 

Koji Kawamura commented on NIFI-4169:
-

Hi [~ywik], I just wanted to share my progress on this.

I'm still in the process of reviewing but found couple of duplicated flag and 
counter variables in the code. Also I found that adding "unknown session" 
relationship may be useful to separate failure scenarios, but 'failure' and 
'retry' are generally used and easier to understand from users perspective. A 
possibly better approach is, with configuration level error or non-existing 
session id, route to 'failure' as the incoming FlowFile would fail if it's 
routed back, otherwise (i.e IOException) penalize and route it to 'retry'.

For better review process and discussion, I created a Github Pull Request based 
on your proposed patch. Still reading and learning proposed change, also fixing 
it for better maintainability. It's not completed but available here.
https://github.com/apache/nifi/pull/2105

> PutWebSocket processor with blank WebSocket session id attribute cannot 
> transfer to failure queue
> -
>
> Key: NIFI-4169
> URL: https://issues.apache.org/jira/browse/NIFI-4169
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Y Wikander
>  Labels: patch
> Attachments: 
> 0001-websocket-when-sendMessage-fails-under-blank-session.patch, 
> 0002-websocket-PutWebSocket-enhance-broadcast-support.patch
>
>
> If a PutWebSocket processor is setup with a blank WebSocket session id 
> attribute (see NIFI-3318; Send message from PutWebSocket to all connected 
> clients) and it is not connected to a websocket server it will log the 
> failure and mark the flowfile with Success (rather than Failure) -- and the 
> data is effectively lost.
> If there are multiple connected clients, and some succeed and others fail, 
> routing Failure back into the PutWebSocket could result in duplicate data to 
> some clients.
> Other NiFi processors seem to err on the side of "at least once".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136133#comment-16136133
 ] 

ASF GitHub Bot commented on NIFI-4169:
--

GitHub user ijokarumawak opened a pull request:

https://github.com/apache/nifi/pull/2105

NIFI-4169: WIP PutWebSocket broadcast failure handling

**NOTE**
Submitting this PR just for code review purpose. Not ready to be merged yet.

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ijokarumawak/nifi nifi-4169

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2105.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2105


commit 8ca63ae87b0dfe6c44f9d1f0ef86167968df26cd
Author: Koji Kawamura 
Date:   2017-08-21T22:47:23Z

Contribution from Y Wikander.

commit 2f0dfe1be9df4e59d3128924d386d382fb1850b1
Author: Koji Kawamura 
Date:   2017-08-22T01:30:37Z

NIFI-4169: WIP PutWebSocket broadcast failure handling




> PutWebSocket processor with blank WebSocket session id attribute cannot 
> transfer to failure queue
> -
>
> Key: NIFI-4169
> URL: https://issues.apache.org/jira/browse/NIFI-4169
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Y Wikander
>  Labels: patch
> Attachments: 
> 0001-websocket-when-sendMessage-fails-under-blank-session.patch, 
> 0002-websocket-PutWebSocket-enhance-broadcast-support.patch
>
>
> If a PutWebSocket processor is setup with a blank WebSocket session id 
> attribute (see NIFI-3318; Send message from PutWebSocket to all connected 
> clients) and it is not connected to a websocket server it will log the 
> failure and mark the flowfile with Success (rather than Failure) -- and the 
> data is effectively lost.
> If there are multiple connected clients, and some succeed and others fail, 
> routing Failure back into the PutWebSocket could result in duplicate data to 
> some clients.
> Other NiFi processors seem to err on the side of "at least once".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2105: NIFI-4169: WIP PutWebSocket broadcast failure handl...

[ijokarumawak]

GitHub user ijokarumawak opened a pull request:

https://github.com/apache/nifi/pull/2105

NIFI-4169: WIP PutWebSocket broadcast failure handling

**NOTE**
Submitting this PR just for code review purpose. Not ready to be merged yet.

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ijokarumawak/nifi nifi-4169

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2105.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2105


commit 8ca63ae87b0dfe6c44f9d1f0ef86167968df26cd
Author: Koji Kawamura 
Date:   2017-08-21T22:47:23Z

Contribution from Y Wikander.

commit 2f0dfe1be9df4e59d3128924d386d382fb1850b1
Author: Koji Kawamura 
Date:   2017-08-22T01:30:37Z

NIFI-4169: WIP PutWebSocket broadcast failure handling




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp issue #131: MINIFI-388 symlink versioned libcrypto/libssl to...

[achristianson]

Github user achristianson commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/131
  
Updated to disable dynamic loading of TLS libs in civet, install libressl 
instead of openssl to resolve conflict with libcurl deps, and backport fix for 
civetweb which fixes compatibility with libressl.

Basically, libcurl and civet were using conflicting TLS versions. This 
worked due to dynamic loading of openssl libs, but turning that off and having 
both depend on libressl removes the duplication while also solving MINIFI-388.

This should be more of a "proper"/lasting fix. The civet patch backport 
will go away on the next version of civet.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-4269) GetMongo should be able to provide pure JSON as well as "extended JSON"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135968#comment-16135968
 ] 

ASF GitHub Bot commented on NIFI-4269:
--

Github user MikeThomsen commented on the issue:

https://github.com/apache/nifi/pull/2063
  
@mattyb149 @pvillard31 @bbende @joewitt Could one of you take a look at 
this and give me some feedback? I can fix the merge conflicts that came up 
since I submitted this.


> GetMongo should be able to provide pure JSON as well as "extended JSON"
> ---
>
> Key: NIFI-4269
> URL: https://issues.apache.org/jira/browse/NIFI-4269
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>
> GetMongo currently only supports "extended JSON." That results in ugly JSON 
> like this:
> {
> "timestamp": {
> "$date": LONG_TIMESTAMP
> }
> }
> instead of something cleaner like this:
> {
> "timestamp": "2017-08-07T00:00:00Z"
> }
> GetMongo should be refactored to support both modes of JSON serialization.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2063: NIFI-4269 Added the ability to serialize Mongo documents t...

[MikeThomsen]

Github user MikeThomsen commented on the issue:

https://github.com/apache/nifi/pull/2063
  
@mattyb149 @pvillard31 @bbende @joewitt Could one of you take a look at 
this and give me some feedback? I can fix the merge conflicts that came up 
since I submitted this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Comment Edited] (NIFI-3869) add http/2 support to HTTP listening processors

[Michael Hogue (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135852#comment-16135852
 ] 

Michael Hogue edited comment on NIFI-3869 at 8/21/17 9:17 PM:
--

After changes to {{ListenHTTP}}, i wrote up a really quick performance test to 
see if there were any performance gains/losses. I published the code and 
results on github:

https://github.com/m-hogue/nifi-http2

http2 is faster across the board in my testing for messages ranging in size 
between [10B, 100MB].


was (Author: m-hogue):
After changes to {{ListenHTTP}}, i wrote up a really quick performance test to 
see if there were any changes. I published the code and results on github:

https://github.com/m-hogue/nifi-http2

http2 is faster across the board in my testing for messages ranging in size 
between [10B, 100MB].

> add http/2 support to HTTP listening processors
> ---
>
> Key: NIFI-3869
> URL: https://issues.apache.org/jira/browse/NIFI-3869
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Tony Kurc
>Assignee: Michael Hogue
>Priority: Minor
>
> investigate whether some of the HTTP processors could use HTTP/2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3869) add http/2 support to HTTP listening processors

[Michael Hogue (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135852#comment-16135852
 ] 

Michael Hogue commented on NIFI-3869:
-

After changes to {{ListenHTTP}}, i wrote up a really quick performance test to 
see if there were any changes. I published the code and results on github:

https://github.com/m-hogue/nifi-http2

http2 is faster across the board in my testing for messages ranging in size 
between [10B, 100MB].

> add http/2 support to HTTP listening processors
> ---
>
> Key: NIFI-3869
> URL: https://issues.apache.org/jira/browse/NIFI-3869
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Tony Kurc
>Assignee: Michael Hogue
>Priority: Minor
>
> investigate whether some of the HTTP processors could use HTTP/2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3484) GenerateTableFetch Should Allow for Right Boundary

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135806#comment-16135806
 ] 

ASF GitHub Bot commented on NIFI-3484:
--

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2091#discussion_r134329892
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
 ---
@@ -112,6 +112,17 @@
 
.addValidator(StandardValidators.NON_NEGATIVE_INTEGER_VALIDATOR)
 .build();
 
+public static final PropertyDescriptor RIGHT_BOUND_WHERE = new 
PropertyDescriptor.Builder()
--- End diff --

I just removed it @mattyb149, thanks!


> GenerateTableFetch Should Allow for Right Boundary
> --
>
> Key: NIFI-3484
> URL: https://issues.apache.org/jira/browse/NIFI-3484
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core Framework
>Affects Versions: 1.2.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
>Priority: Minor
>
> When using GenerateTableFetch it places no right hand boundary on pages of 
> data.  This can lead to issues when the statement says to get the next 1000 
> records greater then a specific key, but records were added to the table 
> between the time the processor executed and when the SQL is being executed. 
> As a result it pulls in records that did not exist when the processor was 
> run.  On the next execution of the processor these records will be pulled in 
> a second time.
> Example:
> Partition Size = 1000
> First run (no state): Count(*)=4700 and MAX(ID)=4700.
> 5 FlowFiles are generated, the last one will say to fetch 1000, not 700. (But 
> I don't think this is really a bug, just an observation).
> 5 Flow Files are now in queue to be executed by ExecuteSQL.  Before the 5th 
> file can execute 400 new rows are added to the table.  When the final SQL 
> statement is executed 300 extra records, with higher ID values, will also be 
> pulled into NiFi.
> Second run (state: ID=4700).  Count(*) ID>4700 = 400 and MAX(ID)=5100.
> 1 Flow File is generated, but includes 300 records already pulled into NiFI.
> The solution is to have an optional property that will let users use the new 
> MAX(ID) as a right boundary when generating queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2091: NIFI-3484 GenerateTableFetch Should Allow for Right...

[pvillard31]

Github user pvillard31 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2091#discussion_r134329892
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
 ---
@@ -112,6 +112,17 @@
 
.addValidator(StandardValidators.NON_NEGATIVE_INTEGER_VALIDATOR)
 .build();
 
+public static final PropertyDescriptor RIGHT_BOUND_WHERE = new 
PropertyDescriptor.Builder()
--- End diff --

I just removed it @mattyb149, thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2715) When performing a Queue Listing, if FlowFile has no content, UI does not indicate this fact

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135679#comment-16135679
 ] 

ASF GitHub Bot commented on NIFI-2715:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2100
  
@yuri1969 there are still a few style issues with the 'No Content 
Available' text. It seems you are incorrectly applying a font-size of 12px when 
it should be 13px. Also, you are applying a 'Roboto-Slab' font to the text when 
it should only be 'Roboto'. Let me know when you have updated this PR and I 
will review it again.


> When performing a Queue Listing, if FlowFile has no content, UI does not 
> indicate this fact
> ---
>
> Key: NIFI-2715
> URL: https://issues.apache.org/jira/browse/NIFI-2715
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Mark Payne
>Priority: Minor
>
> I have a queue that has FlowFiles with no content (this is the result of 
> running GetHTMLElement with the destination set to attribute and sending the 
> matching FlowFiles to this queue). When I view the queue listing, the 
> FlowFiles have no Content Claim, but there is no indicator that there is no 
> Content Claim. The UI should specifically indicate this, as it leaves the 
> user confused as to why they are unable to view the content.
> Also, while looking at this, when I view the details of a FlowFile, I found 
> that the File Size was listed as 'no previous value set' because the FlowFile 
> had no content claim.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2100: NIFI-2715 - When performing a Queue Listing, if...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2100
  
@yuri1969 there are still a few style issues with the 'No Content 
Available' text. It seems you are incorrectly applying a font-size of 12px when 
it should be 13px. Also, you are applying a 'Roboto-Slab' font to the text when 
it should only be 'Roboto'. Let me know when you have updated this PR and I 
will review it again.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFIREG-7) Define Flow Persistence Provider Interface

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFIREG-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135525#comment-16135525
 ] 

ASF GitHub Bot commented on NIFIREG-7:
--

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi-registry/pull/5#discussion_r134294952
  
--- Diff: 
nifi-registry-provider-api/src/main/java/org/apache/nifi/registry/flow/FlowProvider.java
 ---
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.registry.flow;
+
+import org.apache.nifi.registry.provider.Provider;
+
+/**
+ * A service that can store and retrieve versioned flow snapshots.
+ *
+ * NOTE: Although this interface is intended to be an extension point, it 
is not yet considered stable and thus may
+ * change across releases until the registry matures.
+ */
+public interface FlowProvider extends Provider {
--- End diff --

Kevin, thanks for taking a look... 

I originally had shortened the name from FlowPersistenceProvider to 
FlowProvider to make some of the supporting classes names less verbose, but 
with the way things turned out I think it is a non-issue now and we can go back 
to calling it FlowPersistenceProvider. I'll make that change and update the PR.

I envision there being a service above the providers, for now I'm calling 
it RegistryService, which would coordinate the operations... So for example, 
there would be a "snapshot method" on the service which would do something like 
the following:
-  Create any necessary versions or ids
-  Call the metadata provider to persist the snapshot metadata
-  Call a serializer to serialize the snapshot
-  Call the flow persistence provider to save the serialized bytes

For the search example, we probably have to think through what we want to 
support searching on. Searching by name is more like searching on metadata, 
where as if someone wants to find a snapshot that contains processor XYZ, then 
that would have to be searching into the content of each snapshot. I could 
potentially see having a "search provider" that separated search into its own 
thing, but need to think through it more.


> Define Flow Persistence Provider Interface
> --
>
> Key: NIFIREG-7
> URL: https://issues.apache.org/jira/browse/NIFIREG-7
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>
> The Flow Persistence Provider will be the interface that the REST/service 
> layer uses to perform CRUD operations on versioned flows. The implementation 
> used by the application should be configurable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-registry pull request #5: NIFIREG-7 Defining Provider API and initial f...

[bbende]

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi-registry/pull/5#discussion_r134294952
  
--- Diff: 
nifi-registry-provider-api/src/main/java/org/apache/nifi/registry/flow/FlowProvider.java
 ---
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.registry.flow;
+
+import org.apache.nifi.registry.provider.Provider;
+
+/**
+ * A service that can store and retrieve versioned flow snapshots.
+ *
+ * NOTE: Although this interface is intended to be an extension point, it 
is not yet considered stable and thus may
+ * change across releases until the registry matures.
+ */
+public interface FlowProvider extends Provider {
--- End diff --

Kevin, thanks for taking a look... 

I originally had shortened the name from FlowPersistenceProvider to 
FlowProvider to make some of the supporting classes names less verbose, but 
with the way things turned out I think it is a non-issue now and we can go back 
to calling it FlowPersistenceProvider. I'll make that change and update the PR.

I envision there being a service above the providers, for now I'm calling 
it RegistryService, which would coordinate the operations... So for example, 
there would be a "snapshot method" on the service which would do something like 
the following:
-  Create any necessary versions or ids
-  Call the metadata provider to persist the snapshot metadata
-  Call a serializer to serialize the snapshot
-  Call the flow persistence provider to save the serialized bytes

For the search example, we probably have to think through what we want to 
support searching on. Searching by name is more like searching on metadata, 
where as if someone wants to find a snapshot that contains processor XYZ, then 
that would have to be searching into the content of each snapshot. I could 
potentially see having a "search provider" that separated search into its own 
thing, but need to think through it more.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[Pierre Villard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Villard updated NIFI-3781:
-
Fix Version/s: 1.4.0

> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
> Fix For: 1.4.0
>
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4307) Add Kotlin support to ExecuteScript

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135492#comment-16135492
 ] 

ASF GitHub Bot commented on NIFI-4307:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2104
  
I had started work in this area as well but hadn't sufficiently tested it 
to make sure it was working. Do you mind taking a look and including anything 
you think is relevant (such as unit tests, the configurator to handle the weird 
bindings thing, etc.)? 
https://github.com/apache/nifi/compare/master...mattyb149:kotlin-scripting?expand=1
I hope to review this week


> Add Kotlin support to ExecuteScript
> ---
>
> Key: NIFI-4307
> URL: https://issues.apache.org/jira/browse/NIFI-4307
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Priority: Minor
>
> Kotlin has a ScriptEngine implementation as of v1.1. Add support for it in 
> NiFi.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2104: NIFI-4307 Added Kotlin 1.1.X support to ExecuteScript.

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2104
  
I had started work in this area as well but hadn't sufficiently tested it 
to make sure it was working. Do you mind taking a look and including anything 
you think is relevant (such as unit tests, the configurator to handle the weird 
bindings thing, etc.)? 
https://github.com/apache/nifi/compare/master...mattyb149:kotlin-scripting?expand=1
I hope to review this week


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135476#comment-16135476
 ] 

ASF GitHub Bot commented on NIFI-3781:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2102
  
Thanks @yuri1969 this has been merged to master.


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135474#comment-16135474
 ] 

ASF subversion and git services commented on NIFI-3781:
---

Commit 05700a20086233cf8dbe7832e165a1959d610a83 in nifi's branch 
refs/heads/master from [~yuri1969]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=05700a2 ]

NIFI-3781 - Change tooltip for disabled state

Signed-off-by: Scott Aslan 

This closes #2102


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[Scott Aslan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Aslan resolved NIFI-3781.
---
Resolution: Fixed

> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135473#comment-16135473
 ] 

ASF subversion and git services commented on NIFI-3781:
---

Commit a3401c3b95361cc895da8e3a1cf47e60d354c311 in nifi's branch 
refs/heads/master from [~yuri1969]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=a3401c3 ]

NIFI-3781 - Controller Service Config Dialog...

..'View Details' button feels confusing and inconsistent with Processors

* Merged 'View Details' and 'Edit' buttons to a single 'Configure'/'View 
Details' one.
* Fixed confusing 'View Details' modal's title.


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135475#comment-16135475
 ] 

ASF GitHub Bot commented on NIFI-3781:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2102


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2102: NIFI-3781 - Controller Service Config Dialog...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2102
  
Thanks @yuri1969 this has been merged to master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #2102: NIFI-3781 - Controller Service Config Dialog...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2102


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFIREG-7) Define Flow Persistence Provider Interface

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFIREG-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135443#comment-16135443
 ] 

ASF GitHub Bot commented on NIFIREG-7:
--

Github user kevdoran commented on a diff in the pull request:

https://github.com/apache/nifi-registry/pull/5#discussion_r134273595
  
--- Diff: 
nifi-registry-provider-api/src/main/java/org/apache/nifi/registry/flow/FlowProvider.java
 ---
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.registry.flow;
+
+import org.apache.nifi.registry.provider.Provider;
+
+/**
+ * A service that can store and retrieve versioned flow snapshots.
+ *
+ * NOTE: Although this interface is intended to be an extension point, it 
is not yet considered stable and thus may
+ * change across releases until the registry matures.
+ */
+public interface FlowProvider extends Provider {
--- End diff --

Would a better name be "FlowPersistenceProvider" as this seems to primarily 
define methods for persistence operations for flows whereas other types of 
operations are defined in the MetadataProvider? Or do you think other 
operations will get added to FlowProvider over time other than persistence?

I want to make sure I fully understand how the two Providers you have in 
this PR are intended to be used together. Is it designed so that atomic 
operations, such as generating new version numbers, are done via the 
MetadataProvider and then the snapshot would be saved/persisted via the 
FlowProvider? Eventually we will probably want to add search (ie, search for 
flow by name). Do you envision that would be added to the MetadataProvider or 
FlowProvider? Again, not requesting a change in this case, just want to make 
sure I follow your thinking.


> Define Flow Persistence Provider Interface
> --
>
> Key: NIFIREG-7
> URL: https://issues.apache.org/jira/browse/NIFIREG-7
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>
> The Flow Persistence Provider will be the interface that the REST/service 
> layer uses to perform CRUD operations on versioned flows. The implementation 
> used by the application should be configurable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-registry pull request #5: NIFIREG-7 Defining Provider API and initial f...

[kevdoran]

Github user kevdoran commented on a diff in the pull request:

https://github.com/apache/nifi-registry/pull/5#discussion_r134273595
  
--- Diff: 
nifi-registry-provider-api/src/main/java/org/apache/nifi/registry/flow/FlowProvider.java
 ---
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.registry.flow;
+
+import org.apache.nifi.registry.provider.Provider;
+
+/**
+ * A service that can store and retrieve versioned flow snapshots.
+ *
+ * NOTE: Although this interface is intended to be an extension point, it 
is not yet considered stable and thus may
+ * change across releases until the registry matures.
+ */
+public interface FlowProvider extends Provider {
--- End diff --

Would a better name be "FlowPersistenceProvider" as this seems to primarily 
define methods for persistence operations for flows whereas other types of 
operations are defined in the MetadataProvider? Or do you think other 
operations will get added to FlowProvider over time other than persistence?

I want to make sure I fully understand how the two Providers you have in 
this PR are intended to be used together. Is it designed so that atomic 
operations, such as generating new version numbers, are done via the 
MetadataProvider and then the snapshot would be saved/persisted via the 
FlowProvider? Eventually we will probably want to add search (ie, search for 
flow by name). Do you envision that would be added to the MetadataProvider or 
FlowProvider? Again, not requesting a change in this case, just want to make 
sure I follow your thinking.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135431#comment-16135431
 ] 

ASF GitHub Bot commented on NIFI-3781:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2102
  
Reviewing...


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2102: NIFI-3781 - Controller Service Config Dialog...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2102
  
Reviewing...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (NIFI-4308) Emptying queue at process group level

[Pierre Villard (JIRA)]

Pierre Villard created NIFI-4308:


 Summary: Emptying queue at process group level
 Key: NIFI-4308
 URL: https://issues.apache.org/jira/browse/NIFI-4308
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Reporter: Pierre Villard


It'd be really useful (in the development phase of the workflows) if a user 
could empty all the queues (recursively) contained by a process group (like 
start/stop). When a user has tens of connections and wants to "re-initialize" 
the workflow to test some changes, emptying queues can be a painful process.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135409#comment-16135409
 ] 

ASF GitHub Bot commented on NIFI-3781:
--

Github user yuri1969 commented on the issue:

https://github.com/apache/nifi/pull/2102
  
@moranr @scottyaslan Changed the tooltip to _View Configuration_.


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2102: NIFI-3781 - Controller Service Config Dialog...

[yuri1969]

Github user yuri1969 commented on the issue:

https://github.com/apache/nifi/pull/2102
  
@moranr @scottyaslan Changed the tooltip to _View Configuration_.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp pull request #131: MINIFI-388 symlink versioned libcrypto/li...

[achristianson]

Github user achristianson commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/131#discussion_r134278520
  
--- Diff: docker/Dockerfile ---
@@ -100,6 +100,10 @@ RUN mkdir -p $MINIFI_BASE_DIR
 COPY --from=builder ${MINIFI_HOME} ${MINIFI_HOME}
 RUN chown -R ${USER}:${USER} /opt/minifi
 
+# Link crypto libs to known locations for civet
+RUN ln -s /usr/lib/libcrypto.so.1.0.0 /usr/lib/libcrypto.so
--- End diff --

Looking into it... that would be a better fix if it works out.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp pull request #131: MINIFI-388 symlink versioned libcrypto/li...

[phrocker]

Github user phrocker commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/131#discussion_r134278103
  
--- Diff: docker/Dockerfile ---
@@ -100,6 +100,10 @@ RUN mkdir -p $MINIFI_BASE_DIR
 COPY --from=builder ${MINIFI_HOME} ${MINIFI_HOME}
 RUN chown -R ${USER}:${USER} /opt/minifi
 
+# Link crypto libs to known locations for civet
+RUN ln -s /usr/lib/libcrypto.so.1.0.0 /usr/lib/libcrypto.so
--- End diff --

why not set the make option with CIVET? It seems like a bandaid that could 
come apart if something within the container changed. Could it be such that our 
make CRYPTO_LIB was determined via an embedded command?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp issue #130: MINIFI-388 symlink versioned libcrypto/libssl to...

[achristianson]

Github user achristianson commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/130
  
Disregard this one. Was based on MINIFI-374 instead of master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp pull request #131: MINIFI-388 symlink versioned libcrypto/li...

[achristianson]

GitHub user achristianson opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/131

MINIFI-388 symlink versioned libcrypto/libssl to non-versioned path s…

…o that civet can find them when TLS is used

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [x] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/achristianson/nifi-minifi-cpp MINIFI-388

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-minifi-cpp/pull/131.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #131


commit 6683974e1352e03a0c6861ef058ffa9bf71e9967
Author: Andrew I. Christianson 
Date:   2017-08-21T16:19:54Z

MINIFI-388 symlink versioned libcrypto/libssl to non-versioned path so that 
civet can find them when TLS is used




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp pull request #130: MINIFI-388 symlink versioned libcrypto/li...

[achristianson]

Github user achristianson closed the pull request at:

https://github.com/apache/nifi-minifi-cpp/pull/130


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp pull request #130: MINIFI-388 symlink versioned libcrypto/li...

[achristianson]

GitHub user achristianson opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/130

MINIFI-388 symlink versioned libcrypto/libssl to non-versioned path so that 
civet can find them when TLS is used

Added symlink cmds to dockerfile to allow civet to find the libraries in 
the expected locations.

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [x] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/achristianson/nifi-minifi-cpp MINIFI-388

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-minifi-cpp/pull/130.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #130


commit 83e748ba6c3af5c3467f470e0fb462e204de55e8
Author: Andrew Christianson 
Date:   2017-07-13T14:42:35Z

MINIFI-350 added pytest-based system integration test framework and initial 
test cases

commit 62f44f3bfaea08bce1f04991b8b693b5bd629d45
Author: Andrew I. Christianson 
Date:   2017-08-18T15:13:35Z

MINIFI-374 WIP

commit 1d550ed2da31dbeaf9b73b5a40184f871e0da4ab
Author: Andrew I. Christianson 
Date:   2017-08-18T15:24:58Z

MINIFI-374 WIP

commit bab47cc8fbe6be6618dbe0a95202d78c0b706295
Author: Andrew I. Christianson 
Date:   2017-08-18T16:19:49Z

MINIFI-374 WIP

commit bd89c08030f0fcc03509bb3177331978b11205f5
Author: Andrew I. Christianson 
Date:   2017-08-21T16:19:06Z

MINIFI-374 WIP

commit bfc842531e130896b0f96b08db4241840ed67ae5
Author: Andrew I. Christianson 
Date:   2017-08-21T16:19:54Z

MINIFI-388 symlink versioned libcrypto/libssl to non-versioned path so that 
civet can find them when TLS is used




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-4307) Add Kotlin support to ExecuteScript

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135380#comment-16135380
 ] 

ASF GitHub Bot commented on NIFI-4307:
--

GitHub user MikeThomsen opened a pull request:

https://github.com/apache/nifi/pull/2104

NIFI-4307 Added Kotlin 1.1.X support to ExecuteScript.

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MikeThomsen/nifi NIFI-4307

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2104.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2104


commit f1c2bc7e5e0eb66a0ed769c2186a9b979180c623
Author: Mike Thomsen 
Date:   2017-08-21T15:23:44Z

NIFI-4307 Added Kotlin 1.1.X support to ExecuteScript.




> Add Kotlin support to ExecuteScript
> ---
>
> Key: NIFI-4307
> URL: https://issues.apache.org/jira/browse/NIFI-4307
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Priority: Minor
>
> Kotlin has a ScriptEngine implementation as of v1.1. Add support for it in 
> NiFi.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2104: NIFI-4307 Added Kotlin 1.1.X support to ExecuteScri...

[MikeThomsen]

GitHub user MikeThomsen opened a pull request:

https://github.com/apache/nifi/pull/2104

NIFI-4307 Added Kotlin 1.1.X support to ExecuteScript.

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MikeThomsen/nifi NIFI-4307

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2104.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2104


commit f1c2bc7e5e0eb66a0ed769c2186a9b979180c623
Author: Mike Thomsen 
Date:   2017-08-21T15:23:44Z

NIFI-4307 Added Kotlin 1.1.X support to ExecuteScript.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi-minifi-cpp pull request #129: MINIFI-375: Update integration test

[phrocker]

GitHub user phrocker opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/129

MINIFI-375: Update integration test

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [ ] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFI-375

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-minifi-cpp/pull/129.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #129


commit f75a94ca2bd7ef6422043ed1720d78005e5f872c
Author: Marc Parisi 
Date:   2017-08-21T16:20:15Z

MINIFI-375: Update integration test




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135294#comment-16135294
 ] 

ASF GitHub Bot commented on NIFI-3781:
--

Github user moranr commented on the issue:

https://github.com/apache/nifi/pull/2102
  
I also commented in original JIRA looking for feedback from some others as 
well.


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2102: NIFI-3781 - Controller Service Config Dialog...

[moranr]

Github user moranr commented on the issue:

https://github.com/apache/nifi/pull/2102
  
I also commented in original JIRA looking for feedback from some others as 
well.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[Rob Moran (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135292#comment-16135292
 ] 

Rob Moran commented on NIFI-3781:
-

[~markap14] – curious if this is what you had in mind? Working as you'd expect?

Also, [~mcgilman] – any concerns here from multi-tenant/authorization 
perspective? Wouldn't want to create a situation where a user with limited 
auths could not access details or perform an action.

> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135286#comment-16135286
 ] 

ASF GitHub Bot commented on NIFI-3781:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2102
  
Will review...


> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-2715) When performing a Queue Listing, if FlowFile has no content, UI does not indicate this fact

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135285#comment-16135285
 ] 

ASF GitHub Bot commented on NIFI-2715:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2100
  
@yuri1969 this is looking good however I have a few comments: For the case 
where the FF has no size the text 'No Content Available' is good but we should 
keep the .flowfile-header 'Content Claim' visible and move the text 'No Content 
Available' below that header and give it an .unset css class.


> When performing a Queue Listing, if FlowFile has no content, UI does not 
> indicate this fact
> ---
>
> Key: NIFI-2715
> URL: https://issues.apache.org/jira/browse/NIFI-2715
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Mark Payne
>Priority: Minor
>
> I have a queue that has FlowFiles with no content (this is the result of 
> running GetHTMLElement with the destination set to attribute and sending the 
> matching FlowFiles to this queue). When I view the queue listing, the 
> FlowFiles have no Content Claim, but there is no indicator that there is no 
> Content Claim. The UI should specifically indicate this, as it leaves the 
> user confused as to why they are unable to view the content.
> Also, while looking at this, when I view the details of a FlowFile, I found 
> that the File Size was listed as 'no previous value set' because the FlowFile 
> had no content claim.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2102: NIFI-3781 - Controller Service Config Dialog...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2102
  
Will review...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (NIFI-4307) Add Kotlin support to ExecuteScript

[Mike Thomsen (JIRA)]

Mike Thomsen created NIFI-4307:
--

 Summary: Add Kotlin support to ExecuteScript
 Key: NIFI-4307
 URL: https://issues.apache.org/jira/browse/NIFI-4307
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Mike Thomsen
Priority: Minor


Kotlin has a ScriptEngine implementation as of v1.1. Add support for it in NiFi.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2100: NIFI-2715 - When performing a Queue Listing, if...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2100
  
@yuri1969 this is looking good however I have a few comments: For the case 
where the FF has no size the text 'No Content Available' is good but we should 
keep the .flowfile-header 'Content Claim' visible and move the text 'No Content 
Available' below that header and give it an .unset css class.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-3781) Controller Service Config Dialog 'View Details' button feels confusing and inconsistent with Processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135282#comment-16135282
 ] 

ASF GitHub Bot commented on NIFI-3781:
--

Github user moranr commented on the issue:

https://github.com/apache/nifi/pull/2102
  
This looks pretty good @yuri1969 . Another thing that would probably makes 
sense is to change the icon's tooltip (title) to 'View configuration' since it 
does not use the view details icon anymore. That, of course, would only happen 
when the controller service is enabled.




> Controller Service Config Dialog 'View Details' button feels confusing and 
> inconsistent with Processors
> ---
>
> Key: NIFI-3781
> URL: https://issues.apache.org/jira/browse/NIFI-3781
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>
> If a Processor is running, the user is able to right-click and "View 
> Configuration." If stopped, the user is able to right-click and "Configure." 
> With Controller Services, however, there is always a "View Details" (which is 
> essentially the same as View Configuration). There is an "Edit" button only 
> when the service is disabled.
> Often, I find myself clicking the "View Details" icon when a service is 
> disabled and trying to configure the service, but I can't because it is a 
> read-only view.
> I recommend removing the "View Details" icon from the left-hand side and 
> instead have the right-hand side offer either "View Configuration" or 
> "Configure" based on whether the service is enabled or disabled. I feel this 
> is more consistent with how Processors work.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2102: NIFI-3781 - Controller Service Config Dialog...

[moranr]

Github user moranr commented on the issue:

https://github.com/apache/nifi/pull/2102
  
This looks pretty good @yuri1969 . Another thing that would probably makes 
sense is to change the icon's tooltip (title) to 'View configuration' since it 
does not use the view details icon anymore. That, of course, would only happen 
when the controller service is enabled.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-4306) UpdateRecord does not allow user to set root path to some child record

[Mark Payne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Payne updated NIFI-4306:
-
Fix Version/s: 1.4.0
   Status: Patch Available  (was: Open)

> UpdateRecord does not allow user to set root path to some child record
> --
>
> Key: NIFI-4306
> URL: https://issues.apache.org/jira/browse/NIFI-4306
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.4.0
>
>
> If i have the following record:
> {code}
> {
>   "queue": {
>  "count": 1,
>  "size": "1 MB"
>   }
> }
> {code}
> And I want to get rid of the 'queue' element I should be able to do so by 
> using UpdateRecord with a property name of "/" and a value of "/queue/*"
> Currently, if I try this, though, I get an error indicating that more than 1 
> element has been selected. We should instead just create a 'record' object 
> with both the 'count' and 'size' fields and set that as the root so that the 
> result is:
> {code}
> {
>   "count": 1,
>   "size": "1 MB"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4306) UpdateRecord does not allow user to set root path to some child record

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135275#comment-16135275
 ] 

ASF GitHub Bot commented on NIFI-4306:
--

GitHub user markap14 opened a pull request:

https://github.com/apache/nifi/pull/2103

NIFI-4306: Allow root field to be updated to a child field by adding …

…property with name / and value /child, for instance

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markap14/nifi NIFI-4306

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2103.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2103


commit 99d05d27f7cd924fbbc47052486bb9f517927934
Author: Mark Payne 
Date:   2017-08-21T15:12:13Z

NIFI-4306: Allow root field to be updated to a child field by adding 
property with name / and value /child, for instance




> UpdateRecord does not allow user to set root path to some child record
> --
>
> Key: NIFI-4306
> URL: https://issues.apache.org/jira/browse/NIFI-4306
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.4.0
>
>
> If i have the following record:
> {code}
> {
>   "queue": {
>  "count": 1,
>  "size": "1 MB"
>   }
> }
> {code}
> And I want to get rid of the 'queue' element I should be able to do so by 
> using UpdateRecord with a property name of "/" and a value of "/queue/*"
> Currently, if I try this, though, I get an error indicating that more than 1 
> element has been selected. We should instead just create a 'record' object 
> with both the 'count' and 'size' fields and set that as the root so that the 
> result is:
> {code}
> {
>   "count": 1,
>   "size": "1 MB"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2103: NIFI-4306: Allow root field to be updated to a chil...

[markap14]

GitHub user markap14 opened a pull request:

https://github.com/apache/nifi/pull/2103

NIFI-4306: Allow root field to be updated to a child field by adding …

…property with name / and value /child, for instance

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markap14/nifi NIFI-4306

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2103.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2103


commit 99d05d27f7cd924fbbc47052486bb9f517927934
Author: Mark Payne 
Date:   2017-08-21T15:12:13Z

NIFI-4306: Allow root field to be updated to a child field by adding 
property with name / and value /child, for instance




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (NIFI-4306) UpdateRecord does not allow user to set root path to some child record

[Mark Payne (JIRA)]

Mark Payne created NIFI-4306:


 Summary: UpdateRecord does not allow user to set root path to some 
child record
 Key: NIFI-4306
 URL: https://issues.apache.org/jira/browse/NIFI-4306
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Reporter: Mark Payne
Assignee: Mark Payne


If i have the following record:

{code}
{
  "queue": {
 "count": 1,
 "size": "1 MB"
  }
}
{code}

And I want to get rid of the 'queue' element I should be able to do so by using 
UpdateRecord with a property name of "/" and a value of "/queue/*"

Currently, if I try this, though, I get an error indicating that more than 1 
element has been selected. We should instead just create a 'record' object with 
both the 'count' and 'size' fields and set that as the root so that the result 
is:

{code}
{
  "count": 1,
  "size": "1 MB"
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-2715) When performing a Queue Listing, if FlowFile has no content, UI does not indicate this fact

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135242#comment-16135242
 ] 

ASF GitHub Bot commented on NIFI-2715:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2100
  
Reviewing


> When performing a Queue Listing, if FlowFile has no content, UI does not 
> indicate this fact
> ---
>
> Key: NIFI-2715
> URL: https://issues.apache.org/jira/browse/NIFI-2715
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Mark Payne
>Priority: Minor
>
> I have a queue that has FlowFiles with no content (this is the result of 
> running GetHTMLElement with the destination set to attribute and sending the 
> matching FlowFiles to this queue). When I view the queue listing, the 
> FlowFiles have no Content Claim, but there is no indicator that there is no 
> Content Claim. The UI should specifically indicate this, as it leaves the 
> user confused as to why they are unable to view the content.
> Also, while looking at this, when I view the details of a FlowFile, I found 
> that the File Size was listed as 'no previous value set' because the FlowFile 
> had no content claim.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2100: NIFI-2715 - When performing a Queue Listing, if...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2100
  
Reviewing


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-4250) Create support for deleting document by id from elasticsearch 5

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135181#comment-16135181
 ] 

ASF GitHub Bot commented on NIFI-4250:
--

Github user mans2singh commented on the issue:

https://github.com/apache/nifi/pull/2045
  
Thanks @mattyb149 


> Create support for deleting document by id from elasticsearch 5
> ---
>
> Key: NIFI-4250
> URL: https://issues.apache.org/jira/browse/NIFI-4250
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, elasticsearch
> Fix For: 1.4.0
>
>
> Create a processor to delete documents from elasticsearch 5 based on document 
> id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2045: NIFI-4250 - Elasticsearch 5 delete processor

[mans2singh]

Github user mans2singh commented on the issue:

https://github.com/apache/nifi/pull/2045
  
Thanks @mattyb149 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #2091: NIFI-3484 GenerateTableFetch Should Allow for Right...

[mattyb149]

Github user mattyb149 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2091#discussion_r134226406
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
 ---
@@ -112,6 +112,17 @@
 
.addValidator(StandardValidators.NON_NEGATIVE_INTEGER_VALIDATOR)
 .build();
 
+public static final PropertyDescriptor RIGHT_BOUND_WHERE = new 
PropertyDescriptor.Builder()
--- End diff --

I can test on Postgres and Oracle, my preference is to remove the property


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-3484) GenerateTableFetch Should Allow for Right Boundary

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135138#comment-16135138
 ] 

ASF GitHub Bot commented on NIFI-3484:
--

Github user mattyb149 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2091#discussion_r134226406
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
 ---
@@ -112,6 +112,17 @@
 
.addValidator(StandardValidators.NON_NEGATIVE_INTEGER_VALIDATOR)
 .build();
 
+public static final PropertyDescriptor RIGHT_BOUND_WHERE = new 
PropertyDescriptor.Builder()
--- End diff --

I can test on Postgres and Oracle, my preference is to remove the property


> GenerateTableFetch Should Allow for Right Boundary
> --
>
> Key: NIFI-3484
> URL: https://issues.apache.org/jira/browse/NIFI-3484
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core Framework
>Affects Versions: 1.2.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
>Priority: Minor
>
> When using GenerateTableFetch it places no right hand boundary on pages of 
> data.  This can lead to issues when the statement says to get the next 1000 
> records greater then a specific key, but records were added to the table 
> between the time the processor executed and when the SQL is being executed. 
> As a result it pulls in records that did not exist when the processor was 
> run.  On the next execution of the processor these records will be pulled in 
> a second time.
> Example:
> Partition Size = 1000
> First run (no state): Count(*)=4700 and MAX(ID)=4700.
> 5 FlowFiles are generated, the last one will say to fetch 1000, not 700. (But 
> I don't think this is really a bug, just an observation).
> 5 Flow Files are now in queue to be executed by ExecuteSQL.  Before the 5th 
> file can execute 400 new rows are added to the table.  When the final SQL 
> statement is executed 300 extra records, with higher ID values, will also be 
> pulled into NiFi.
> Second run (state: ID=4700).  Count(*) ID>4700 = 400 and MAX(ID)=5100.
> 1 Flow File is generated, but includes 300 records already pulled into NiFI.
> The solution is to have an optional property that will let users use the new 
> MAX(ID) as a right boundary when generating queries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4250) Create support for deleting document by id from elasticsearch 5

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135130#comment-16135130
 ] 

ASF GitHub Bot commented on NIFI-4250:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2045


> Create support for deleting document by id from elasticsearch 5
> ---
>
> Key: NIFI-4250
> URL: https://issues.apache.org/jira/browse/NIFI-4250
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, elasticsearch
> Fix For: 1.4.0
>
>
> Create a processor to delete documents from elasticsearch 5 based on document 
> id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (NIFI-4250) Create support for deleting document by id from elasticsearch 5

[Matt Burgess (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Burgess updated NIFI-4250:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Create support for deleting document by id from elasticsearch 5
> ---
>
> Key: NIFI-4250
> URL: https://issues.apache.org/jira/browse/NIFI-4250
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, elasticsearch
> Fix For: 1.4.0
>
>
> Create a processor to delete documents from elasticsearch 5 based on document 
> id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (NIFI-4250) Create support for deleting document by id from elasticsearch 5

[Matt Burgess (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Burgess updated NIFI-4250:
---
Fix Version/s: 1.4.0

> Create support for deleting document by id from elasticsearch 5
> ---
>
> Key: NIFI-4250
> URL: https://issues.apache.org/jira/browse/NIFI-4250
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, elasticsearch
> Fix For: 1.4.0
>
>
> Create a processor to delete documents from elasticsearch 5 based on document 
> id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4250) Create support for deleting document by id from elasticsearch 5

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135126#comment-16135126
 ] 

ASF GitHub Bot commented on NIFI-4250:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2045
  
+1 LGTM, ran the build and tests, and tried a flow with various conditions 
(success, not found, failure), everything works well.  Thanks for the 
contribution!  Merging to master


> Create support for deleting document by id from elasticsearch 5
> ---
>
> Key: NIFI-4250
> URL: https://issues.apache.org/jira/browse/NIFI-4250
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, elasticsearch
>
> Create a processor to delete documents from elasticsearch 5 based on document 
> id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2045: NIFI-4250 - Elasticsearch 5 delete processor

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2045


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-4250) Create support for deleting document by id from elasticsearch 5

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135128#comment-16135128
 ] 

ASF subversion and git services commented on NIFI-4250:
---

Commit 8cb501443bbe27fa043572cc3b993529ff245722 in nifi's branch 
refs/heads/master from [~mans2singh]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=8cb5014 ]

NIFI-4250 - Elasticsearch 5 delete processor

Signed-off-by: Matt Burgess 

This closes #2045


> Create support for deleting document by id from elasticsearch 5
> ---
>
> Key: NIFI-4250
> URL: https://issues.apache.org/jira/browse/NIFI-4250
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, elasticsearch
>
> Create a processor to delete documents from elasticsearch 5 based on document 
> id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2045: NIFI-4250 - Elasticsearch 5 delete processor

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2045
  
+1 LGTM, ran the build and tests, and tried a flow with various conditions 
(success, not found, failure), everything works well.  Thanks for the 
contribution!  Merging to master


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue

[Koji Kawamura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Koji Kawamura updated NIFI-4169:

 Priority: Major  (was: Critical)
Fix Version/s: (was: 1.3.0)

[~ywik] Thanks for updating the patch and detailed explanation. I'm going to 
review it shortly. I made following changes to this ticket:

- Lowered Priority from Critical to Major, as this issue has a work-around by 
using non-broadcasting.
- Removed Fix version. We set "Fix version" to the next targeted release 
version, when the fix is merged into master branch.

> PutWebSocket processor with blank WebSocket session id attribute cannot 
> transfer to failure queue
> -
>
> Key: NIFI-4169
> URL: https://issues.apache.org/jira/browse/NIFI-4169
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Y Wikander
>  Labels: patch
> Attachments: 
> 0001-websocket-when-sendMessage-fails-under-blank-session.patch, 
> 0002-websocket-PutWebSocket-enhance-broadcast-support.patch
>
>
> If a PutWebSocket processor is setup with a blank WebSocket session id 
> attribute (see NIFI-3318; Send message from PutWebSocket to all connected 
> clients) and it is not connected to a websocket server it will log the 
> failure and mark the flowfile with Success (rather than Failure) -- and the 
> data is effectively lost.
> If there are multiple connected clients, and some succeed and others fail, 
> routing Failure back into the PutWebSocket could result in duplicate data to 
> some clients.
> Other NiFi processors seem to err on the side of "at least once".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)