leaves12138 commented on code in PR #62:
URL:
https://github.com/apache/paimon-vector-index/pull/62#discussion_r3651378468
##########
jni/src/stream.rs:
##########
@@ -79,6 +80,28 @@ impl SeekRead for JniSeekableStream {
copy_java_buffers(&mut env, &buffers, ranges)
}
+
+ fn try_clone_reader(&self) -> io::Result<Option<Self>> {
+ Ok(Some(self.clone()))
+ }
+
+ fn read_capabilities(&self) -> SeekReadCapabilities {
+ let Ok(mut env) = self.jvm.attach_current_thread() else {
+ return SeekReadCapabilities::default();
+ };
+ let read_hint = |env: &mut jni::JNIEnv<'_>, name: &str| -> usize {
+ env.call_method(self.stream_ref.as_obj(), name, "()J", &[])
+ .ok()
Review Comment:
Could we avoid swallowing `call_method` failures here? If a custom
`VectorIndexInput` implementation throws from one of these capability methods,
`jni` returns `Error::JavaException` but the Java exception remains pending.
This code converts the failure to `0` and continues opening the native reader;
when the native method returns, the pending exception is propagated and the
newly allocated reader handle is unreachable/leaked. The subsequent hint calls
also run with an exception already pending. Please either read/validate these
hints before constructing the reader and propagate the error, or explicitly
clear the exception if falling back to zero is intentional. Negative hint
values should probably be rejected consistently as well rather than silently
becoming zero.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
