@bmoisson ,   I believe the best alternative for you would be to use a fixed schema rather than "Infer Schema". Create a parameter with the schema that specifies the exact structure and data types that you want to use and configure your RecordReader setting that parameter in the "Schema Text" property of the RecordReader and setting the Schema Strategy to "Use Schema Text".   Cheers, André   -- Did this response answer your question? If so, please take a moment to click on "Accept as Solution" below this post. If you find a reply useful, say thanks by clicking on the thumbs up button.   ... View more

Hi @Olivia_4692 ,   The only issue I can see here is that in your sample data "Before" has a capital B, while you your EvaluateJSONPath configuration it's all in lowercase. This will certainly create a problem for your logic.   I tried your data (converting "Before" to "before") and it worked correctly in my test.   Please my test flow attached.   Cheers, André   -- Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button. ... View more

@Jarinek ,   This is total volume, in bytes, received from the network by all the brokers across the cluster. Replication traffic is counted by this counter as well.   Cheers, André   -- Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button. ... View more

Hi, @templarian ,   From your log I can see that thread 13 got stuck right after this line:   2022-03-02 16:31:37,479 DEBUG [Timer-Driven Process Thread 13 ] jakarta.mail getProvider() returning jakarta.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Oracle]     Looking at other threads, the line that should've come right after that would be one like this:   com.sun.mail.smtp connected to host "smtp.office365.com", port: 587     It seems to me that the thread got stuck during the attempt to connect to the SMTP server. I was able to reproduce this locally and confirmed that after the socked connection is established, if the server response is lost for some reason (or if the server doesn't respond at all) the processor thread gets stuck forever.   Apparently this is kind of by design, since the default value of the mail.smtp.timeout property is infinite, as you can see here.   I had a look at the PutEmail processor source code and unfortunately I don't think there is a way currently to set this in the processor configuration.   I'd suggest that you open a NiFi Jira in https://issues.apache.org/ asking for the configurable timeout to be added. If you have support with Cloudera, please open a ticket and we should be able to help with that.   Cheers, André   -- Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.   ... View more