comphead commented on PR #2031: URL: https://github.com/apache/datafusion-comet/pull/2031#issuecomment-3084571582
> This patch looks good to me, and it reminds me another problem with fs-hdfs. > > The `HdfsErr` returned by `fs-hdfs` read functions does not contain JVM stack traces. If there's a read failure caused by an exception in JVM, all we get is an `Err(HdfsErr::Generic)` with a vague error message. The stack trace will only be printed to stderr by libhdfs but not get propagated to the Java exception thrown by Comet. User has to browse the executor logs to know what happened when a query failure was caused by fs-hdfs read failure. > > libhdfs has `getLastTLSExceptionRootCause` and `getLastTLSExceptionStackTrace` for retrieving detailed information about the exception, but fs-hdfs is not making use of them. > > An ideal approach is to rethrow the original Java exception using `env.throw`, just like how Comet handles other JNI call exceptions. But this requires revising how Java exception objects are managed in libhdfs. Actually it calls out once again of having opportunity to tweak `fs-hdfs` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org For additional commands, e-mail: github-h...@datafusion.apache.org
