[Bug] When calling the interface of the TRIPLE protocol, after a long time of free, it always fails for the first time

[Alleninggx]

Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Dubbo java 3.2.5
Java 21
Spring Boot 3.2.3
Alibaba Spring Cloud 2023.0.0.0-RC1
Seata 2.0
Nacos

Steps to reproduce this issue

我有一个triple协议的服务，提供了一个读文件的服务端流（详见最底的proto文件，read函数）。
I have a Triple protocol service, which provides a server stream for reading files (see the bottom Proto file for details, read function).

问题：
Question:
服务启动时，访问此接口是正常的（能打印“bbb”），我命名这次为 Action-A。
但是不做操作过1~2个小时候后，调此接口，就没有再执行成功了（没有打印出“bbb”），我命名这次为 Action-B。
然后紧接着再调用此接口，又正常了，我命名这次为 Action-C。
When the service starts, the access to this interface is normal (it can print "BBB"), and I named this time Action-A.
However, after 1 to 2 hours, the interface was adjusted, and it was not successfully executed (the "BBB" was not printed). I named it Action-B this time.
Then call this interface immediately, it is normal, I named this time Action-C.

---

@DubboService(protocol = "tri", retries = 1)           // Has been tried to 0 or 1
@RequiredArgsConstructor
public class ExcelFileResourceDubboGrpcImpl implements ExcelFileResourceDubboGrpc {
    @Override
    public void read(ReadRequest readRequest, StreamObserver<ReadResult> responseObserver) {
        System.err.println("bbb");         //  Looking forward to printing "bbb", but not
    }
}

syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.xxxxxxxxxxx.protobuf.ExcelFileResource";

package proto.ExcelFileResource;

service ExcelFileResourceDubboGrpc {
  // 读取
  rpc read(ReadRequest) returns (stream ReadResult) {}
}

// Ignore the definition of message

dubbo:
  application:
    name: ${spring.application.name}
    qos-enable: false
    # 3.2.0+默认为严格模式
    serialize-check-status: WARN
    # 3.2.0+默认为true
    check-serializable: false
    trust-serialize-class-level: 4
  registry:
    address: nacos://${spring.cloud.nacos.discovery.server-addr}
    parameters.namespace: ${definition.nacos-namespace.mes-dubbo-registry}
  provider:
    retries: 0
    validation: jvalidationNew
    token: true
    timeout: 60000
  consumer:
    # 在启动时检查依赖的服务是否可用
    check: false
    retries: 0
    validation: jvalidationNew
    timeout: 60000
  protocols:
    dubbo:
      name: dubbo
      port: -1
      default: true
    tri:
      name: tri
      port: -1
      default: false

What you expected to happen

期初我以为是dubbo有关于“长时间空闲”的策略，但是我没找到相关信息。
At first I thought dubbo had a "long idle" policy, but I couldn't find that information.

然后我尝试增加重试次数，但意外的是，它并不像是“失败”，而是“无响应”，并没触发重试。
I then tried to increase the number of retries, but to my surprise, it didn't look like "failed", it looked like "no response" and didn't trigger a retry.

Anything else

No response

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[AlbumenJ]

@EarthChen PTAL

[EarthChen]

麻烦你开启 debug 日志，然后重新复现一下 然后把中间那次失败日志提供一下

[EarthChen]

建议你使用最新版本试试