Hi Alexey If possible, I think you could move some RDBMS maintenance operations to the #open method of RichFunction to reduce the possibility of blocking processing records.
Best Yun Tang ________________________________ From: Alexey Trenikhun <yen...@msn.com> Sent: Tuesday, January 28, 2020 15:15 To: Yun Tang <myas...@live.com>; user@flink.apache.org <user@flink.apache.org> Subject: Re: Blocking KeyedCoProcessFunction.processElement1 Thank you Yun Tang. My implementation potentially could block for significant amount of time, because I wanted to do RDBMS maintenance (create partitions for new data, purge old data etc) in-line with writing stream data to a database ________________________________ From: Yun Tang <myas...@live.com> Sent: Sunday, January 26, 2020 8:42:37 AM To: Alexey Trenikhun <yen...@msn.com>; user@flink.apache.org <user@flink.apache.org> Subject: Re: Blocking KeyedCoProcessFunction.processElement1 Hi Alexey Actually, I don't understand why you thing KeyedCoProcessFunction#processElement1 would block for significant amount of time, it just process record from the elements in the first input stream which is necessary. If you really find it would block for a long time, I think that's because your processing logic has some problem to stuck. On the other hand, since processing checkpoint and records hold the same lock, we cannot process checkpoint when the record processing logic did not release the lock. Best Yun Tang ________________________________ From: Alexey Trenikhun <yen...@msn.com> Sent: Thursday, January 23, 2020 13:04 To: user@flink.apache.org <user@flink.apache.org> Subject: Blocking KeyedCoProcessFunction.processElement1 Hello, If KeyedCoProcessFunction.processElement1 blocks for significant amount of time, will it prevent checkpoint ? Thanks, Alexey
