You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by david-streamlio <gi...@git.apache.org> on 2018/02/26 16:06:03 UTC
[GitHub] nifi pull request #2493: Added Pulsar processors and Controller Service
GitHub user david-streamlio opened a pull request:
https://github.com/apache/nifi/pull/2493
Added Pulsar processors and Controller Service
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-XXXX where XXXX 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/david-streamlio/nifi NIFI-4908
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/2493.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 #2493
----
commit e4f8550159132d85d0e19d61f24e087e51742dee
Author: David Kjerrumgaard <da...@...>
Date: 2018-02-24T01:40:22Z
Added Pulsar processors and Controller Service
----
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by joewitt <gi...@git.apache.org>.
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2493
please update all the nifi component version references to 1.6.0-SNAPSHOT
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
When I started writing these processors, I used the Kafka ones as a model. However, I felt that it would be easier to configure the Pulsar client once, such as SSLContextService integration, and then pool both the Producer and Consumers for re-use, similar to a connection pool for a database.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by tasanuma <gi...@git.apache.org>.
Github user tasanuma commented on the issue:
https://github.com/apache/nifi/pull/2493
Hi @david-streamlio. Thanks for the work. This would really helpful for Pulsar users.
I have one question. Are there any reasons that this processor uses Controller Service? I think this is similar to Kafka processors, but they don't use Controller Service.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by markap14 <gi...@git.apache.org>.
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/2493
Hey @david-streamlio this is very cool! I've been thinking about writing processors for interacting with Pulsar myself but haven't had a chance yet. Just a few things that we should think through a bit:
- Re: Connection Pool in controller service vs. doing it in the processor: what makes sense here I think depends on how you expect to use it. If you expect to be creating several Pulsar processors with the same connection info, then a Controller Service makes sense. If you think the more common case will be a single instance of the Processor then configuring it in the Processor is probably easier for the user. I think both have their merits though, so I'm fine with either approach personally.
- One concern that I have is that with the Kafka processors, we end up having to create a new copy of the processors with pretty much each release of Kafka, so that we can take advantage of the new features. Have you considered how you see this evolving as more versions of Pulsar are released? There are two approaches that we often see with NiFi. One is to create a new processor for each new version as we did with Kafka. The other is to have a "Client Service" Controller service. It would then have methods like publish(FlowFile), consume() or something like that. Then there is only a single ConsumePulsar processor and a single PublishPulsar processor. Each is then just configured with the controller service that handles interacting with Pulsar directly. Either approach is okay, I think. But we should probably think about naming at least - does it make sense to name these ConsumePulsar_1_20 or ConsumePulsar_1_0 or something of that nature? I think it's best to figure this part out
before the initial release because it can then become confusing if we have processors like ConsumePulsar and ConsumePulsar_1_35 for instance.
Thoughts?
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
I have rebased my branch and created new pull request here: https://github.com/apache/nifi/pull/2553. Please ignore this pull request as the new one supersedes it.
---
[GitHub] nifi pull request #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2493#discussion_r171295857
--- Diff: nifi-nar-bundles/nifi-pulsar-client-services/nifi-pulsar-client-service-api/src/main/java/org/apache/nifi/pulsar/PulsarClientPool.java ---
@@ -0,0 +1,47 @@
+/*
+ * 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.pulsar;
+
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.controller.ControllerService;
+import org.apache.nifi.pulsar.pool.ResourcePool;
+
+
+@Tags({"Pulsar"})
+@CapabilityDescription("Provides the ability to create Pulsar Producer / Consumer instances on demand, based on the configuration."
+ + "properties defined")
+public interface PulsarClientPool extends ControllerService {
+
+ /*
--- End diff --
Will do.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
I created a separate JIRA for record-based processors.....https://issues.apache.org/jira/browse/NIFI-4914, but would like to get these processors into the release as well. Primarily because Pulsar doesn't currently have schemas or a schema registry, so writing records to Pulsar doesn't help the downstream consumers much. Unless they use the ConsumePulsarRecord processor.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
NIFI-4908
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
At the risk of sounding pushy.....Is there anything else I need to do on this PR, such as add the record-based processors?
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by joewitt <gi...@git.apache.org>.
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2493
@david-streamlio @markap14 i'd recommend we dont even bother with non record based producers/consumers with Pulsar.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by markap14 <gi...@git.apache.org>.
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/2493
@david-streamlio the idea behind the record-oriented processors is that they make building your flow in NiFi much easier. Without that, you end up having to split your data up into tons of FlowFiles and then push each one individually to Pulsar. So you would have to use a SplitText, SplitJson, SplitAvro, etc. type of processor if the data is already 'batched together.' But if we had a PublishPulsarRecord, you can skip having to split the data up. It turns out that splitting the data up becomes quite expensive because instead of a single FlowFile containing 10,000 records you now have 10,000 FlowFiles, each with their own attributes, their own Provenance events, etc. So the record-oriented processors allow the flow to be much more efficient, and they also allow easy conversion, validation, etc. so the flows are also easier to build and maintain. So even without a schema registry integrated into Pulsar, the record-oriented approach is very helpful for the users building the flow.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
I completely agree on your observation about having to land the entire, unbroken file into NiFi's repo rather than streaming through memory is inefficient. I will talk to the Pulsar team about getting a true streaming API implemented. It is a great suggestion.
If we were to write such an API, do you have some examples of how we would leverage it inside NiFi? I thought we had to generate a flow file for our Consumer processor. Is there a way to hand off streams instead?
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
The Pulsar client API, https://pulsar.apache.org/api/client/, currently only supports byte[] payloads. By true streaming, I am assuming you mean an API that return an IO stream object of some sort.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
Thanks @markap14. This has been a great learning experience for me, and I am happy to contribute back to such a great project. I am still new to developing processors, so I really appreciate the feedback on my design and these are great points I hadn't considered.
- I decided to go with a ControllerService, because I envision the user will only have 1 or 2 Pulsar clusters they are interacting with, therefore it made more sense to have a controller service that the user can configure once (Broker URL & SSL ControllerService), and pull Publishers and Consumers. from. I believe that the common usage pattern will be to have small number of Producers, that leverage the expression language to route the messages to multiple topics. I would expect Consumers to be configured to a single topic/subscription pair to feed data into the flow.
- I have not given much thought to how we are going to handle Pulsar client evolution from these processors to be honest, as I don't expect the API to change drastically. Having said that, I think it is safe to at least associate these with the major version number of Pulsar just in case there is a major functionally shift between 1.x and 2.x. I am ok with naming these ConsumerPulsar_1_0.
- Can you point me to an example of the "Client Service" Controller pattern you mention? I would like to examine that.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
I have updated all the nifi component version references to 1.6.0-SNAPSHOT, and successfully rebuilt the project using mvn -Pcontrib-check clean install.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
Sure, I will start re-basing now.
---
[GitHub] nifi pull request #2493: Added Pulsar processors and Controller Service
Posted by markap14 <gi...@git.apache.org>.
Github user markap14 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2493#discussion_r171294580
--- Diff: nifi-nar-bundles/nifi-pulsar-client-services/nifi-pulsar-client-service-api/src/main/java/org/apache/nifi/pulsar/PulsarClientPool.java ---
@@ -0,0 +1,47 @@
+/*
+ * 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.pulsar;
+
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.controller.ControllerService;
+import org.apache.nifi.pulsar.pool.ResourcePool;
+
+
+@Tags({"Pulsar"})
+@CapabilityDescription("Provides the ability to create Pulsar Producer / Consumer instances on demand, based on the configuration."
+ + "properties defined")
+public interface PulsarClientPool extends ControllerService {
+
+ /*
--- End diff --
Can probably get rid of these lines that are commented out
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by pvillard31 <gi...@git.apache.org>.
Github user pvillard31 commented on the issue:
https://github.com/apache/nifi/pull/2493
@david-streamlio HBase is an example of what @markap14 suggested.
https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-standard-services
and there is a new PR (#2498) currently opened that is adding a new service for HBase 2 without modifying anything in all the related HBase processors that are located in this bundle:
https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-hbase-bundle
---
[GitHub] nifi pull request #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio closed the pull request at:
https://github.com/apache/nifi/pull/2493
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by joewitt <gi...@git.apache.org>.
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2493
@david-streamlio i'm supportive of doing non record ones for the cases you mention. Does Pulsar by any chance offer a true streaming API instead of byte[] then so handling the types of objects you describe is feasible? We are doing the memory warning annootations so that will help too but would be awesome if they do..
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by MikeThomsen <gi...@git.apache.org>.
Github user MikeThomsen commented on the issue:
https://github.com/apache/nifi/pull/2493
Pulsar looks interesting, so if you can do the rebase I'll try to help out with the review.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by joewitt <gi...@git.apache.org>.
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2493
yes correct it would be awesome if the client/broker interface could support a genuinely streaming interface rather than a byte[] as this helps frameworks that can operate on the streams rather than having objects fully loaded operate in the most GC/efficient manner possible. It means sending a 1 GB object for example never holds more than some small buffer size in memory. If you want to suppor the use case you're describing then nifi has to load the full image/document/etc.. into a byte[] then hand that over to the pulsar interface. So, larger objects become a problem in terms of efficiency/parallelism. no biggie for now but does make that use case a bit less exciting for now :)
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by MikeThomsen <gi...@git.apache.org>.
Github user MikeThomsen commented on the issue:
https://github.com/apache/nifi/pull/2493
@david-streamlio Looks like you pulled in about 30 some commits from other folks into this. Can you rebase the branch so that only your commits are part of the PR?
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by joewitt <gi...@git.apache.org>.
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2493
on the consume side you would generate a flowfile. But you'd then write to it via the streaming API. #neverbytearray is a movement we should start.
---
[GitHub] nifi issue #2493: Added Pulsar processors and Controller Service
Posted by david-streamlio <gi...@git.apache.org>.
Github user david-streamlio commented on the issue:
https://github.com/apache/nifi/pull/2493
@markap14. I completely agree that is the best approach for handling text-based payloads into and out of Pulsar, and am starting to work on the record based processors now. However, I do see a need for keeping the non record based processors around to handle non-text payloads, such as image files, audio files, scientific data, etc.
---