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.
---
