mobile: check for pending exceptions after JNI call#24361
Conversation
|
CC @envoyproxy/mobile-maintainers: FYI only for changes made to |
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
This reverts commit 479b7f8936a9e50c25be20ed798347042ebcfda6. Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
8ac1784 to
f566610
Compare
alyssawilk
left a comment
There was a problem hiding this comment.
cool, thanks for tackling this!
/wait
| // JvmCallbackContext | ||
|
|
||
| static void pass_headers(const char* method, envoy_headers headers, jobject j_context) { | ||
| static void pass_headers(const char* method, const Envoy::Types::ManagedEnvoyHeaders& headers, |
There was a problem hiding this comment.
I thought these all had to be simple (C) types. can you clue me in on why it's OK use ManagedEnvoyHeaders?
edit: nm I think I see why. if this isn't called from Java layers can we use standard passHeaders naming to make that clear?
There was a problem hiding this comment.
I thought these all had to be simple (C) types. can you clue me in on why it's OK use ManagedEnvoyHeaders?
the usage of c types is a self-imposed limitations in many places in our code. Decided to use c++ type in here to make mem management simpler.
edit: nm I think I see why. if this isn't called from Java layers can we use standard passHeaders naming to make that clear?
OK
| // TODO(Augustyniak): Pass the name of the filter in here so that we can instrument the origin of | ||
| // the JNI exception better. | ||
| if (exception_check(env)) { | ||
| env->DeleteLocalRef(j_stream_intel); |
There was a problem hiding this comment.
can the DeleteLocalRefs be moved outside of the exception check? alternately if the exception check needs to happen before deletion
bool saw_exception = exception_check(env)
deletelocalRef
deletelocalRef
if (saw_exception) {...
| env->DeleteLocalRef(j_stream_intel); | ||
| env->DeleteLocalRef(jcls_JvmCallbackContext); | ||
|
|
||
| return result; |
There was a problem hiding this comment.
to proxy Ryan, let's do this first, and do
if (!exception) {
return result
}
// handle exception
| jobject result = | ||
| env->CallObjectMethod(j_context, jmid_onComplete, j_stream_intel, j_final_stream_intel); | ||
|
|
||
| exception_check(env); |
There was a problem hiding this comment.
comment on why it's Ok to clear without handling?
| jni_delete_global_ref(const_cast<void*>(context)); | ||
| } | ||
|
|
||
| bool exception_check(JNIEnv* env) { |
There was a problem hiding this comment.
I'd be inclined to ABSL_MUST_USE_RESULT for this. or at least make it clear we're clearing
There was a problem hiding this comment.
I do not think that it always have to be handled explicitly. Per ur suggestion, will change method's name to imply that it clears any pending exceptions
0f8783f to
bda8425
Compare
Signed-off-by: Rafal Augustyniak <raugustyniak@lyft.com>
|
|
||
| static void* jvm_on_headers(const char* method, envoy_headers headers, bool end_stream, | ||
| envoy_stream_intel stream_intel, void* context) { | ||
| static void* jvm_on_headers(const char* method, const Envoy::Types::ManagedEnvoyHeaders& headers, |
There was a problem hiding this comment.
this one isn't called by jvm directly either. optional nit onHeadersFromJvm or something
There was a problem hiding this comment.
it's calling a method from the java world tho which I think is why it has a jvm prefix (pass_headers - now renamed to passHeaders- method did not havejvmprefix as it was/is not calling intojvm`).
I do not have a strong opinion in here but will keep the things they are until we figure out new naming patterns for this file - ideally in a separate PR.
…-cpp-to-latest-version * origin/main: (23 commits) Reduce Route memory utilization by avoiding RuntimeData instances when not needed (#24327) build: fix compile error for mac (#24429) postgres: support for upstream SSL (#23990) iOS: split `EnvoyEngine.h` into multiple header files (#24397) mobile: check for pending exceptions after JNI call (#24361) Remove uneccessary `this->` from mobile engine builder (#24389) Add setRequestDecoder to ResponseEncoder interface (#24368) downstream: refactoring code to remove listener hard deps (#24394) lb api: moving load balancing policy specific configuration to extension configuration (#23967) ci: Skip docker/examples verification for docs or mobile only changes (#24417) ci: run mobile GitHub Actions on every PR (#24407) mobile: remove `bump_lyft_support_rotation.sh` script (#24404) Add file size to DirectoryEntry (#24176) bazel: update to 6.0.0rc4 (#24235) bazel: update rules_rust (#24409) Ecds config dump recommit (#24384) bazel: add another config_setting incompatible flag (#24270) listeners: moving listeners to extension directory (#24248) mobile: build Swift with whole module optimization (#24396) ci: update `actions/setup-java` from v1 to v3.8 (#24393) ... Signed-off-by: JP Simard <jp@jpsim.com>
Commit Message: Check for pending exceptions after some of the Java calls from within the JNI layer. At Lyft, we noticed that we have a bunch of crashes related to us not checking for exceptions after on_request_headers or/and on_response_headers methods.
Additional description: I tried to use
ENVOY_LOG_EVENT_TO_LOGGERto log when we detect a pending exception but ran into issues with deadlocks. Got rid of the extra logging to unblock my change.Risk Level: Low, mostly additive change. New code executes for when the library crashes previously.
Testing: Integration test
Docs Changes:
Release Notes:
Platform Specific Features: