Thanks for you response! Yes, I think to 99.9% there shouldn't be a "late event" and I would also implement a logic in the ProcessFunction, which checks for a specific order of the events per transaction id.
Using the clear() function for the state should free the ressources and using that many short running keys shouldn't be a problem, correct? As far as I understand it right the keyby function hashes the key and every key (with the data) is assigned to a worker / thread. There is nothing that gets persisted here so that a high number of short living unique keys shouldn't be a problem, correct? -- Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/
