Environment

  • Dubbo version: 3.1.10
  • Operating System version: MacOS 13.4
  • Java version: zulu JDK 1.8.0_372

Steps to reproduce this issue

server use BIDIRECTIONAL_STREAM mode with triple protocol, client use grpc protocol

  1. git clone https://github.com/chaoyoung/dubbo-tri-bistream-test.git
  2. Run org.example.dubbo.DubboTripleVoiceChatProvider#main
  3. Run org.example.dubbo.DubboGrpcVoiceChatConsumer#main

Expected Behavior

No error

Actual Behavior

io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after 0.981473792s. [buffered_nanos=71961167, remote_addr=localhost/127.0.0.1:50051]

[29/05/23 10:54:15:015 CST] grpc-default-executor-0 ERROR dubbo.DubboGrpcVoiceChatConsumer: voice chat onError
io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after 0.981473792s. [buffered_nanos=71961167, remote_addr=localhost/127.0.0.1:50051]
    at io.grpc.Status.asRuntimeException(Status.java:539)
    at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:487)
    at io.grpc.internal.DelayedClientCall$DelayedListener$3.run(DelayedClientCall.java:489)
    at io.grpc.internal.DelayedClientCall$DelayedListener.delayOrExecute(DelayedClientCall.java:453)
    at io.grpc.internal.DelayedClientCall$DelayedListener.onClose(DelayedClientCall.java:486)
    at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:576)
    at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:70)
    at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:757)
    at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:736)
    at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
    at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:750)

Comment From: AlbumenJ

@EarthChen @icodening PTAL

Comment From: yuvashreenarayanan3

Let me take up this issue.

Comment From: sunheyi6

@chaoyoung VoiceChat class does not exist Apache Dubbo io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after 0.981473792s. [buffered_nanos=71961167, remote_addr=localhost/127.0.0.1:50051]

Comment From: vedansh-5

Hey, I'm fairly new to open source, I'd like to contribute, I want to work on this issue, can you please assign it to me.

Comment From: shravyapatel2803

I am new to open source. What I have do in this ?

Comment From: zrlw

contribute pr: 1. fork dubbo into your own repositories 2. git clone the codes from your dubbo repository 3. check out 3.3 branch 4. new pr branch based on 3.3 5. fix the codes 6. commit and push the changed codes to your dubbo repository 7. browse your dubbo repository and you will find a pr creation notification, just follow its step to create a pr for your changes.

Comment From: CAICAIIs

I cloned the repository provided by the issue reporter and tried to reproduce the problem. Here are my findings:

Test Results: 1. Triple server with Triple client: works normally, bidirectional streaming is successful. 2. gRPC server with gRPC client: works normally, bidirectional streaming is successful. 3. Triple server with gRPC client: after about 10 seconds, the client receives a DEADLINE_EXCEEDED error.

Analysis: This issue is caused by a lack of compatibility between the Dubbo Triple protocol and the gRPC protocol in bidirectional streaming mode. Although both protocols are based on HTTP/2, there are differences in their implementations, which leads to communication failures and timeouts when they are mixed.

Conclusion and Suggestion: To avoid this problem, it is recommended to use the same protocol for both the server and the client—either both use Triple, or both use gRPC. Mixing the two protocols is not supported for bidirectional streaming scenarios. Additionally, I noticed that when the protocols are mixed, some data may be exchanged at first, but the connection will eventually time out due to protocol differences. This explains why partial communication may appear to succeed before the error occurs.