On Tue, Feb 8, 2022 at 10:15 PM mayank kulshreshtha <[email protected]> wrote:
> the expectation was that the messages which i will receive in observer > will be out of order > StreamObserver (and ClientCall.Listener) are not thread-safe, so gRPC serializes callbacks into them. as ClientCallImpl<ReqT, RespT>.class has > callExecutor.execute(new MessagesAvailable()); > Yes, but callExecutor is the user's executor wrapped in a SerializingExecutor <https://github.com/grpc/grpc-java/blob/fbb1dbf7a519671331decf5ab3e0ed9716e1823a/core/src/main/java/io/grpc/internal/ClientCallImpl.java#L114> . this.callExecutor = new SerializingExecutor(executor); > is this an expected behaviour? > Yes, it is. It is *very hard* for applications to manage the events if they arrive out-of-order. It is much easier for users to implement a non-thread-safe class. -- 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/CA%2B4M1oNkB_GAo%3DR2OPq%3DvgPDdvJg3M%2B4CqN%3DBf5y8zzHmVXoQA%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
