[
https://issues.apache.org/jira/browse/NIFI-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15019254#comment-15019254
]
Joseph Witt commented on NIFI-1192:
-----------------------------------
[~ozhurakousky] I totally get the approach you did and had you had the luxury
of being the first implementer this would have been good to go. The problem
with this is that the processor property names cannot be changed. You can
change display names all you need but you cannot change the name itself as that
means existing processors in people's flows will break. So need to revert the
names to their original form. When building new processors it is totally green
field to name properties, static values, and so on however you like best
provided it has some degree of consistency with the rest of the code base.
However, when you go into patch an existing processor/extension/etc.. you
really need to play by the rules laid down by the original author for the most
part. So please do go back to its original form and then try the fix again. I
think you have the right approach with property additions, supporting the
dynamic property, avoiding allowance of dynamic properties to be set when they
would conflict with a processor property. So just knock that out.
As an additional consideration it also seems like you sorted out the blocking
time in the OnScheduled. [~markap14] reports he didn't really intend for
connections to be made there. If you think it would be fairly easy to do would
you mind moving any connection logic to be within the onTrigger method instead
of OnScheduled? That isn't essential to do now but if it makes sense while
you're in there please do. Finally, we should be sure that we set reasonable
and small defaults and perhaps even limit the timeout length allowed for values
which effect how long code leaves our control and is blocking. That way even
if we're having a bad zookeeper day or related we don't tie up a
thread/resource too long.
One of the things we should be sure of is that once the processor starts and is
sending/receiving data that if we lose the connection to Kafka for any reason
that it will automatically resume without user intervention required. Is that
accounted for in its existing form? Would it be accounted for if you move the
connection creation to be solely in the onTrigger?
Thanks
Joe
> Allow Get/PutKafka to honor dynamic properties
> ----------------------------------------------
>
> Key: NIFI-1192
> URL: https://issues.apache.org/jira/browse/NIFI-1192
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 0.3.0
> Reporter: Oleg Zhurakousky
> Assignee: Oleg Zhurakousky
> Priority: Critical
> Fix For: 0.4.0
>
>
> Currently Kafka does not honor dynamic properties which means aside from 8
> properties exposed none others could be set
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
