On Mon, Nov 15, 2021 at 1:13 PM Eric Anderson <[email protected]> wrote:
>
> On Mon, Nov 15, 2021 at 12:55 AM Christopher Meiklejohn 
> <[email protected]> wrote:
>>
>> To achieve this, I've made a custom interceptor that throws an exception 
>> (or, creates a Status of a particular type like FAILED_PRECONDITION, and 
>> converting that to an exception) and throwing in the sendMessage callback, 
>> where I can access the message contents.
>
>
> Interceptors should not throw. Generally interceptors should call 
> Listener.onClose() instead. But that also means you must not pass the 
> listener to `next`, because then it will also call onClose().
>
>> Before I throw the exception, I call delegate().halfClose() and *do not* 
>> call super.sendMessage.
>
>
> You can have an RPC without a message. Streaming RPCs can work this way. You 
> are creating a new RPC, and then gracefully closing it, but the RPC still 
> exists.
>
>> Should this be happening?  Any insights on how I can go about debugging 
>> exactly what is happening?
>
>
> You should delay calling `next` (which creates a new RPC) from the 
> interceptor until you are certain the RPC will be needed (i.e., that you 
> won't inject a failure).
>
> The Client Cache Example is in a similar situation to you, as it needs to 
> avoid sending an RPC if there is a cache hit. Your code will be a bit 
> simpler, because you don't need CachingListener, but the 
> interceptCall+ForwardingClientCall code is appropriate to look at. 
> Unfortunately, the current code in master suffers from actually sending the 
> RPC unnecessarily, so you can look at my branch that has sketched out a 
> better approach (again, pay most attention to 
> interceptCall+ForwardingClientCall):
> https://github.com/ejona86/grpc-java/blob/caching-interceptor-avoid-rpcs/examples/android/clientcache/app/src/main/java/io/grpc/clientcacheexample/SafeMethodCachingInterceptor.java
>
> Essentially, it 1) avoids calling `next` until it is certain it needs an RPC 
> and 2) caches method calls until it has made its decision.

Hi Eric,

Thanks for your response.  I was able to refactor my code matching the
example you provided.  I can't thank you enough -- this was an
extremely useful example that helped me understand both the proper way
to do this and what was actually happening underneath it all.

Christopher

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAGVmt0XE_2OOZ8YYiShha3NzdoMn7d6v6V57WpMdFqjWF-6SUg%40mail.gmail.com.

Reply via email to