Support Questions

Find answers, ask questions, and share your expertise

Bug when copying a SplitJson processor

avatar
New Contributor

Hello All, 

 

I have encountered a rather weird bug with NiFi's SplitJson processor. I am using NiFi 1.18 and it's a three node cluster. I think the best way of explaining it will be to use as example, so here is how to recreate this bug:

 

AlexLasecki_0-1671449603421.png

 

I created this flow with the following sequence of steps:

  1. Create a GenerateFlowFile and set the custom text to: { "test": [ { "A": 1 } ], "test2": [ { "B": 1 } ] }
  2. Create the top SplitJson and set the path to: $.test.*
  3. Create all connections for the top SplitJson (original is terminated), start it and run GenerateFlowFile once -> The output queue should show a single flow file with this content: { "A": 1 }
  4. Now select the top SplitJson, Crtl+C, Crtl+V, move the copy down create its connections and set the path to: $.test2.*
  5. Start the bottom SplitJson, and run GenerateFlowFile once again
  6. Both output queues have a new flow file and the contents of both flow files are: { "A": 1 }, which is correct for the top SplitJson, but for the bottom one the value should be { "B": 1 }

It seems that, for some reason, the copied SplitJson continues operating using the path that it had at the moment of copying and not the one that is present in the settings of the processor. I've checked that after refreshing the view or even the page, the settings of the bottom SplitJson show $.test2.* (so it is not a issue of my browser client not conveying the change to the cluster successfully, as the value stays) and yet the output of the copied SplitJson continuous to be { "A": 1 } instead of { "B": 1 }.

 

Is this a known issue? If so is there a fix for it?

Perhaps someone could quickly check if this issue is still present on 1.19, we could update our cluster if it was fixed.

 

Best regards,
Aleksander

1 ACCEPTED SOLUTION

avatar
Master Mentor

@AlexLasecki 
The issue here is unrelated to the copy and paste action taken.  There is a bug in the code where the jsonPath cache is not cleared when the property value is changed after it has been initially set.  So the same issue happens even if you do not copy and paste a splitJson processor configured with json path property value.  All you need to do is change the json path value after after already having a value set.  Original json path property value that is cached still gets used.

The following bug jira has been created and work is already in progress to address the issue. 
https://issues.apache.org/jira/browse/NIFI-10998

For now as a workaround, you'll need to create a new SplitJson processor anytime you want to change the json path property value.

If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.

Thank you,

Matt

View solution in original post

2 REPLIES 2

avatar
Master Mentor

@AlexLasecki 

I can reproduce in 1.19.1 as well. Let me look more in to this issue.  I'll respond again once I determine issue here. 

Thanks,

Matt

avatar
Master Mentor

@AlexLasecki 
The issue here is unrelated to the copy and paste action taken.  There is a bug in the code where the jsonPath cache is not cleared when the property value is changed after it has been initially set.  So the same issue happens even if you do not copy and paste a splitJson processor configured with json path property value.  All you need to do is change the json path value after after already having a value set.  Original json path property value that is cached still gets used.

The following bug jira has been created and work is already in progress to address the issue. 
https://issues.apache.org/jira/browse/NIFI-10998

For now as a workaround, you'll need to create a new SplitJson processor anytime you want to change the json path property value.

If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.

Thank you,

Matt