The flow that you are trying to implement is not very efficient and it's hard to achieve what you want to do in that way. You should try to refactor it using record-based processors, which is much simpler and more efficient to handle a large number of records.   Something like this: ExecuteSQLRecord -> QueryRecord -> PutDatabaseRecord   ExecuteSQLRecord - Query and stream records from the source database QueryRecord - convert the records from the source to target format. (e.g. SELECT id, value FROM FLOWFILE) PutDatabaseRecord - insert the converted records into the target database. André ... View more

@an_dutra  My guess is that it's a misconfiguration on your cluster. I just tested this on my Kafka cluster and once the certificate expires, if I try to connect to the cluster with a Kafka client I get the following exception:   Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: ... Caused by: java.security.cert.CertPathValidatorException: validity check failed ... Caused by: java.security.cert.CertificateExpiredException: NotAfter: Tue Feb 08 03:45:00 UTC 2022 The Kafka brokers will continue to run, though. However, if they are stopped and I try to start them again, they will fail to start with the same exception as the one above. ... View more

What @DigitalPlumber said. Also make sure that Match Requirement is set to "content must contain match", otherwise it won't work. ... View more

You need to find out what's the serializer that's being used to write data to Kafka and use an associated deserializer to read those messages. ... View more

Without having more information, it seems to me that the content of your metadata file is not correct. It seems to be a SAML Assertion, rather than a SAML Metadata document. ... View more

Hi, Minh,   How and where from did you generate the metadata.xml file?   André ... View more

You can try the following Jolt spec in a JoltTransformRecord processor to change the name of one or more columns: Jolt Transformation DSL: Chain Jolt Specification: [ { "operation": "shift", "spec": { "*": "&", "surname": "lastname" } }, { "operation": "remove", "spec": { "surname": "" } } ]   ... View more

That's an odd thing to do 🙂 If you need to use another port for some reason, it would be better to change the ports on all hosts consistently, using the "TCP Port" or the "TLS/SSL Port" properties in Cloudera Manager, whether are you connecting without TLS or with it, respectively.   It is possible to configure ports on a host-by-host basis, but it makes it harder to maintain and client configuration becomes a little more cumbersome. To change the port for a particular host, go to Kafka > Instances > Click on the broker your want the change the port for > Configuration > Continue Editing Role Instance.   Then enter the following in the "Kafka Broker Advanced Configuration Snippet (Safety Valve) for kafka.properties" property: port=9096 listeners=PLAINTEXT://:9096   The PLAINTEXT value will depend on your cluster config: PLAINTEXT: No Kerberos, No TLS SSL: No Kerberos, Using TLS SASL_PLAINTEXT: Using Kerberos, No TLS SASL_SSL: Using Kerberos, Using TLS After that restart the Broker instance that was reconfigured. ... View more

Some more examples here: https://github.com/asdaraujo/cdp-examples ... View more