Exceptions thrown in a Flink streamlet are not logged anywhere.
See original GitHub issueDescribe the bug
A clear and concise description of what the bug is.
Exceptions thrown in a Flink streamlet are not logged anywhere.
for instance throwing an exception in buildExecutionGraph
or throwing an exception in a
readStream(in).map {
// throw here
}
Is not showing up in any logs.
To Reproduce Modify for instance taxi-ride app to throw exceptions in the processor.
Expected behavior To see exception stacktraces in the logs, and a restart of the pod.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
How to catch the exception thrown from flink's readFile(path)?
It can work when file is valid,. but if gzip file is invalid, flink job will be killed. There is exception log: java.io.IOException:...
Read more >lightbend/cloudflow - Gitter
Help with a little logging problem, please. When starting our project in runLocal and in OKD, it was noticed that the settings for...
Read more >An exception is thrown out when recover job timers ... - Apache
An exception is thrown out when recover job timers from checkpoint file. Status: Assignee: Priority: Resolution:.
Read more >Mastering - Kafka Streams and ksqlDB
log). When we talk about logs in this book, we're not referring to ... Throw an exception and stop processing (giving the developers...
Read more >Webinar: Debugging Flink Tutorial - Seth Wiesman - YouTube
As stream processing is being adopted by an enterprise for mission-critical applications, it is important to ensure your systems are robust, ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi @franciscolopezsancho
I apologize in advance in case I’ve missed some parts of your investigation.
The interesting question is to investigate how Cloudflow together with Lyft operator under the hood handles automatic job recovery in cases when the job fails due to some “recoverable” reasons. There is a great example available on YouTube - here.
Hi @franciscolopezsancho
Thanks for the great investigation.
We’ve also observed a faulty behavior in case of JM pod restarts. So are you able to walk through the following steps using your example?
In the default (not HA-mode) JM becomes a single point of failure, so the Flink operator relies on the default K8s politics considering pod re-scheduling. So it would be also great to repeat the same scenario against some Flink cluster with JM running in HA-mode.
Thanks in advance for any assistance!