4 - 协议层 on Apache Dubbo

4-1 - 不支持的协议

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

这种情况可能出现在自定义 Protocol 的场景下。Dubbo 的 SPI 机制找不到 URL 中所指定的 Protocol。

排查和解决步骤

确定 Consumer 中有服务端所用到的 Protocol 的依赖。
确定 Protocol 的依赖包的 SPI 配置文件的名字没有写错。

另请参阅 Dubbo SPI 概述
 协议扩展说明

4-2 - 序列化优化器初始发生错误

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

当前使用了 Kryo 和 FST 的序列化配置。

排查和解决步骤

Kryo 和 FST 序列化

4-3 - 接口引用调用失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

根据指定的协议参数，未找到暴露的服务接口或方法。

排查和解决步骤

可根据接口 URL 及方法名称，确认服务端是否存在。

4-4 - 非安全序列化方式

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

当前在使用非安全的序列化器, 并不推荐。具体配置为：serialization="java"

Java 序列化是不安全的。Dubbo 团队不推荐任何人使用它。如果你仍然想使用它，请遵循 JEP 290 来设置序列化过滤器，以防止反序列化泄露。

排查和解决步骤

修改serialization的参数值. 将 protocol 内的序列化参数值修改为其他,如hessian2，fastjson2等。

4-5 - 流关闭异常

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

提示信息，不影响程序的执行结果。

排查和解决步骤

可通过一些第三方的工具或者jstack [PID] > jstack.log 分析堆栈信息，进行定位。

4-6 - 反序列化失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

发生在使用自定义的序列化方式的时候，在自定义 SPI org.apache.dubbo.common.serialize.Serialization 序列化方法在使用时发生错误。

排查和解决步骤

可通过一些第三方的工具或者 jstack [PID] > jstack.log 分析堆栈信息，获取引起错误的对象内容，再配合自定义实现进行修改。

参考序列化扩展

4-7 - 关闭客户端时发生错误

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

见于各种 Connect Client 进行close或者destory的时候报错，不影响最终效果。

排查和解决步骤

可通过一些第三方的工具或者 jstack [PID] > jstack.log 分析堆栈信息，进行定位。

4-8 - 关闭服务端时发生错误

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

与4-7相似，都是发生在close时。

排查和解决步骤

可通过一些第三方的工具或者jstack [PID] > jstack.log 分析堆栈信息，进行定位。

4-9 - 解析失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

一般为参数值不符合规则，在强转时发生错误。如：

String timeoutString = httpMetadata.headers().getFirst(TripleHeaderEnum.SERVICE_TIMEOUT.getHeader());
Long timeout = Long.parseLong(timeoutString);

Long timeout = GrpcUtils.parseTimeoutToMills(timeoutString);
invocation.put(CommonConstants.TIMEOUT_KEY, timeout);

排查和解决步骤

根据堆栈信息提示的 key 名称进行相对应的配置修改到符合转换规则即可。

4-10 - Triple 序列化结果失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

一般为内部错误。见于三种log格式：

在序列化并且发送数据时发生异常，日志格式为 Serialize triple request failed, service=%s method=%s
接收到response的reset code时触发,日志格式为：Triple Client received remote reset errorCode=xxx
处理response时有异常情况时触发，日志格式为： Meet Exception on ClientResponseHandler, status code is:xxx

排查和解决步骤

针对第一种错误，是在调用{service}#{method}方法过程中出现的，具体对应到sendMessage，并且该日志与java.util.concurrent.ExecutionException: org.apache.dubbo.rpc.StatusRpcException: INTERNAL : Serialize request failed同时出现，排查{method}方法参数中自定义类是否实现序列化接口导致序列化失败

针对第二种错误，是Provider端处理发生错误，排查Provider端服务，排查方式参考第一种错误

针对第三种错误，仅单元测试使用到，目前用户侧不会出现

其次可通过一些第三方的工具或者 jstack [PID] > jstack.log 分析堆栈信息，进行定位。

同时请在社区提交Issue，帮助我们更好的完善Triple 直接点击右上角 提交项目问题 按钮即可快速链接至Github页面

4-11 - 发起请求失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

服务方已关闭。
调用方的 IP 不在服务方的白名单内。
请求具体的地址服务不存在。

排查和解决步骤

检查服务方启动运行情况。
检查或使用第三方工具，测试网络环境是否可正常连接。
根据堆栈的 serviceName, 在管理平台里查看或模拟调用，看是否正常。

4-12 - 创建Triple流失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

一般为内部错误。

排查和解决步骤

可通过一些第三方的工具或者 jstack [PID] > jstack.log 分析堆栈信息，进行定位。

同时请在社区提交Issue。

4-13 - 服务端超时

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

服务端逻辑处理相对耗时。
服务端负载请求过高，无法响应。
当前的超时参数设置阈值与现实情况相差较大。

排查和解决步骤

根据接口名称查看是否存在耗时处理情况。
可监控服务器状态，及服务端调用的服务调用情况。
尝试将超时参数调大一些。

4-14 - 响应结果失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

服务端管道可能因网络原因暂时断开。
当前使用版本较低或可检查当前的参数配置，是否启用 send.reconnect=true, 高版本默认为 true。

排查和解决步骤

检查直连网络是否通畅，有无丢包现象。
检查上述参数值，或尝试使用高版本。

4-15 - 客户端流监听器

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

当收到服务端的响应之后，客户端流监听器会输出此信息，用于提醒。

排查和解决步骤

4-16 - 服务已关闭

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

在错误的状态下继续调用 org.apache.dubbo.rpc.protocol.tri.service.TriHealthImpl#enterTerminalState 或者 org.apache.dubbo.rpc.protocol.ReferenceCountInvokerWrapper#invoke，在调用时已经是 terminal 或 destory状态。

排查和解决步骤

多次调用上述方法会进行提醒。一般仅用于单元测试。

4-17 - 关闭所有调用程序时发生错误

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

一般为内部错误。

排查和解决步骤

可通过一些第三方的工具或者 jstack [PID] > jstack.log 分析堆栈信息，进行定位。

同时请在社区提交issue.

4-18 - 无法从调用中获取服务模型

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

当前仅用于单元测试场景，服务模型默认会进行初始化。

排查和解决步骤

4-19 - 参数值有出错的可能

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

这个错误码提示参数值可能不再正确。

目前出现在同一个协议同时监听多个端口下。由于设计限制，单个协议只能监听一个端口，否则端口配置会被覆盖掉。

排查和解决步骤

调整协议和端口的监听关系。

该错误码的意义已经调整。对于 Dubbo 3.1.4、3.2.0-beta.3 及其之前的版本的该错误码的出错，请参考错误码 0-2。

4-20 - 数据解码失败

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

只发生在解码阶段，可能服务方和调用方的dubbo版本不匹配。

排查和解决步骤

检查当前使用的 dubbo 版本，尽量保持一致或向下兼容的高版本。

4-21 - 检测到不安全的序列化数据

Mon, 01 Jan 0001 00:00:00 +0000

可能的原因

当前服务端可能受到攻击或者是 Dubbo 内置的类检查逻辑没有扫描到您所定义的类。

排查和解决步骤

如果请求源是攻击源，请及时进行安全加固。
如果请求源是预期的，请在 security/serialize.allowlist 资源文件中声明您所使用的类名，Dubbo 将自动将其加载到安全列表中。请参考类检查机制一文。

当前 Dubbo 可以工作在监控模式和限制模式下。监控模式只打印日志，不进行拦截；限制模型将进行拦截。