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

Georgy commented on NIFI-5593:
------------------------------

Can be closed. Don't have any questions.

> ConsumeKafka_0_11 topic name variable is not evaluated correctly
> ----------------------------------------------------------------
>
>                 Key: NIFI-5593
>                 URL: https://issues.apache.org/jira/browse/NIFI-5593
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 1.5.0
>         Environment: RHEL 7.3
> JAVA Oracle 1.8.0_144
> NiFi 1.5.0
> Processor name "ConsumeKafka_0_11"
>            Reporter: Georgy
>            Priority: Major
>         Attachments: proc_prop.PNG, proc_sched.PNG, proc_sett.PNG
>
>
> Hi guys,
> Found that "Topic Name" specified as expression "dmp_order_${now() 
> :minus(3600000) :format('HH') }" is not evaluated correctly in 
> "ConsumeKafka_0_11" processor after next hour begins.
> It is evaluated as expected after processor start/restart only.
> Say, the processor is started at 15:05. Value of "Topic name" variable will 
> be "dmp_order_14". It's correct. It will consume data from the topic and 
> everything is ok.
> After next hour begins, value of "Topic name" is not evaluated as 
> "dmp_order_15". I see that consumer still tries to consume data from topic 
> with name "dmp_order_14".
> I tried both Scheduling strategies "Timer driven" and "CRON driven" but have 
> no success. Seems, I have to restart processor every time I want to 
> re-evalueate "Topic name" variable.
> When I filled CustomText field with now() expression in "GenerateFlowFile" 
> processor I didn't have such issues. It worked as expected with "CRON driven" 
> strategy.
> Can you say is it a bug or normal behaviour for ConsumeKafka processor? 
> And if it is a normal behaviour can you say is there any opportunity to 
> change "Topic name" dynamically in running processor?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to