0 - Common 层 on Apache Dubbo

0-1 - 线程池资源枯竭

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

服务端的线程资源耗尽了。默认情况下，Dubbo 服务端的业务线程数是 200 个。如果多个并发请求量超过了 200，就会拒绝新的请求，抛出此错误。

可能的原因

Consumer 的并发请求量太大，导致 Provider 端创建的线程数量超限。
可能 Provider 端在执行业务的时候，由于业务调用外部应用接口，导致线程出现阻塞，从而导致线程池回收不了线程。

排查和解决步骤

开启 Dubbo 的访问日志功能，排查是否有短时间内大量调用 RPC 服务的情况。
通过 jps 和 jstack 指令检查线程池中各个线程的状态，看下是否有业务调用外部应用接口造成阻塞。
如果是 Consumer 的并发请求量太大，那么调整 Provider 端的 dubbo.provider.threads 参数，将 Dubbo 的线程池的数目调大。
如果 Provider 业务的 QPS 实在太大，目前的服务器数目处理不完，那么增加 Provider 端服务器的数量，让更多的服务器分担压力。

这个错误码的 FAQ 页面参考了空冥同学的《Dubbo 常见错误及解决方法》。所引文章通过 CC-BY-4.0 协议赋予了汇编的权利。在此向原作者表示感谢。

0-2 - 非法属性值

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

可能的原因

这个提示是指用户配置的值与属性本身所需的数据类型并不匹配。比如 dubbo.comsumer.threads 属性只能接受数值属性，但是用户所输入的值混入了字母。

排查和解决步骤

根据配置项参考手册，查找出错的配置项，检查该项指定的类型，检查是否出现类型不一致的情况。

0-3 - 无法访问缓存路径

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

其它模块复用了 Common 层的基于文件的缓存机制（目前是元数据模块），而 Common 层的文件缓存机制无法访问它指定的目录。

2022-08-29 00:35:00,189 ERROR [org.apache.dubbo.common.cache.FileCacheStoreFactory:?] - [DUBBO] Cache store path can't be created: , dubbo version: , current host: 10.0.1.1, error code: 0-3. This may be caused by inaccessible of cache path, go to https://dubbo.apache.org/faq/0/3 to find instructions. 
java.nio.file.FileAlreadyExistsException: [Path]
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:87)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:521)
	at java.base/java.nio.file.Files.createDirectory(Files.java:700)
	at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:807)
	at java.base/java.nio.file.Files.createDirectories(Files.java:753)
	at org.apache.dubbo.common.cache.FileCacheStoreFactory.getInstance(FileCacheStoreFactory.java:90)
	...

可能的原因

多个 Dubbo 进程（或其他 Java 进程）使用了同一个缓存文件。
由于缓存文件所在目录的文件系统权限问题，导致读写失败。

排查和解决步骤

根据下面显示的实际异常找到访问不了的目录，确定下它的文件访问权限。
确定下是否有别的 Dubbo 实例正在访问这个路径。
尝试配置 Java System Property（用 -D 配置的 Java 系统属性） dubbo.meta.cache.filePath 和 dubbo.mapping.cache.filePath，将它指定成一个当前用户能够完全控制的目录下。

0-4 - 缓存条目超限

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

其它模块复用了 Common 层的基于文件的缓存机制（目前是元数据模块），而 Common 层的文件缓存机制 “发觉” 条目超限。

可能的原因

用户不合理地配置了 Java System Property （用 -D 配置的 Java 系统属性） dubbo.mapping.cache.entrySize 或者 dubbo.meta.cache.entrySize

默认值

dubbo.mapping.cache.entrySize	dubbo.meta.cache.entrySize
10000	100

排查和解决步骤

尝试重新配置上述 Java System Property（用 -D 配置的 Java 系统属性）。
如果确实没有配置这些 System Property，请到 GitHub Issue Tracker 下发 Issue。

0-5 - 缓存文件大小超限

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

其它模块复用了 Common 层的基于文件的缓存机制（目前是元数据模块），而 Common 层的文件缓存机制 “发觉” 文件大小超限。

可能的原因

用户不合理地配置了 Java System Property （用 -D 配置的 Java 系统属性） dubbo.mapping.cache.maxFileSize 或者 dubbo.meta.cache.maxFileSize
缓存文件因文件系统或磁盘错误而被破坏。

dubbo.mapping.cache.maxFileSize 和 dubbo.meta.cache.maxFileSize 没有显示默认值，而根据 org.apache.dubbo.common.cache.FileCacheStore.LimitedLengthBufferedWriter 的逻辑而查到的最大文件大小的默认值为：Long.MAX_VALUE ( 2⁶³-1 ) 。

排查和解决步骤

尝试重新配置上述 Java System Property（用 -D 配置的 Java 系统属性）。
删除缓存文件夹重启 Provider 和 Consumer （缓存文件夹的位置一般在 ~/.dubbo。如果配置了 dubbo.meta.cache.filePath 和 dubbo.mapping.cache.filePath 则为该路径）。
如果确实没有配置这些 System Property，请到 GitHub Issue Tracker 下发 Issue。

0-6 - 线程中断异常

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

可能的原因

运行中的线程在处于 wait、sleep、join 时，被显示调用 interrupt()

排查和解决步骤

正常运行的线程在调用了 interrupt() 方法后，将对当前线程中断状态设置为 true，但线程的执行并不会受到影响。可根据实际情况进行操作或检查业务代码有无被错误使用。

0-7 - 未找到反射类

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

可能的原因

一般是 Class.forName(className) 执行此方法时，找不到 className 当前类。
业务代码上显示排除了当前 className 类，导致加载时未找到。

排查和解决步骤

检查 Class.forName(className) 中，className 是否存在。
排查业务代码，有没有使用配置或扫描注解 exclude 排除了一些类或包。

0-8 - 反射失败

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

可能的原因

在反射调用某方法时，未对当前方法设置正确的参数类型值，也就是参数类型不匹配。

排查和解决步骤

检查是否存在未正确设置相匹配的类型值。

0-9 - 通知事件失败

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

可能的原因

自定义的监听器，在处理上产生了运行时异常。

排查和解决步骤

检查实现 org.apache.dubbo.rpc.ExporterListener 接口的业务类，实现方法可能存在代码逻辑错误。

0-10 - 当前调用不在支持

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

可能的原因

当前调用的方法可能已经被弃用或声明了 @Deprecated，不影响执行结果。

排查和解决步骤

请使用其它可替代的 API 方法。

0-11 - 服务停止失败

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

可能的原因

连接没有及时关闭或内存不足，导致服务在停止时会出现一些异常。

排查和解决步骤

在响应内容完成后进行关闭连接。

0-12 - 未知异常

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

未知异常，一般为API使用或配置异常

可能的原因

转码异常、不支持的加解密方法等等

排查和解决步骤

可根据堆栈信息，进行业务代码行定位。

0-13 - 指标收集器发生异常

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

可能的原因

指标数据在推送过程中发生错误，推送的服务器连接不上或一些配置错误，目前支持 Prometheus。

排查和解决步骤

请参考配置项参考手册配置项参考手册。

0-14 - 监控异常

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

用来统计 RPC 调用次数和调用耗时时间，扩展接口为 MonitorFactory，对应的实现类为 DubboMonitorFactroy。

可能的原因

用户可以实现该层的 MonitorFactory 扩展接口，实现自定义监控统计策略。在自定义监控统计策略的实现类，发生了业务运行时异常。

排查和解决步骤

检查 org.apache.dubbo.monitor.MonitorFactory 接口的业务类，实现方法可能存在代码逻辑错误。

0-15 - 加载扩展类时发生异常

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

可能的原因

clazz 类并没有实现当前扩展点的接口类。
扩展名可能是个接口或者不存在。

排查和解决步骤

检查扩展类声明，并没有与之相匹配的扩展实现类。
扩展实现类需实现扩展点接口类以及方法。

0-16 - 没有可用的执行器

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

可能的原因

内部执行器不可用，此时返回空。

排查和解决步骤

不需要进行干预，dubbo 内部会执行createExecutorIfAbsent 方法构建一个新的执行器。

0-17 - 执行器在关闭时发生未知异常

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

可能的原因

可能使用了自定义的执行器，在编写销毁方法时，产生了异常。

排查和解决步骤

检查是否自定义实现 org.apache.dubbo.common.threadpool.manager.ExecutorRepository,检查自定义的 shutdown 方法。

0-18 - 线程池执行器被错误使用

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

可能的原因

自定义设置了线程数量，系统内部发生了未知异常。

排查和解决步骤

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

0-19 - 处理任务时发生异常

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

可能的原因

自定义业务类处理逻辑不当。

排查和解决步骤

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

0-20 - 存储堆栈信息时发生异常

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

可能的原因

JVM设置了参数 -XX:+DisableAttachMechanism
设置了系统不存在的堆栈转储路径，不存在情况，系统会尝试进行创建，创建时发生了 SecurityException, 可能是没有权限。

排查和解决步骤

检查 JVM 是否设置了如上参数。
检查当前启动服务的账号，是否有权限进行创建文件夹。

0-21 - 构建的实例过多

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

可能的原因

一般指 org.apache.dubbo.common.timer.HashedWheelTimer 创建的实例过多。

排查和解决步骤

不影响实例的构建，可能存在内存泄露的风险。

0-22 - 输入输出流异常

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

可能的原因

读取不再可用的本地文件。
尝试读取/写入文件但没有权限。
尝试写入文件但磁盘空间不再可用。

排查和解决步骤

检查本地文件是否存在。
检查文件权限。
检查磁盘空间。

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

0-23 - 序列化数据转换异常

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

可能的原因

待序列化数据中存在循环引用，导致堆栈溢出。
引用的 jar 包版本低或存在兼容性问题。

排查和解决步骤

如使用 FastJson，去掉 SerializerFeature.DisableCircularReferenceDetec
检查下或升级版本进行尝试。

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

0-24 - 覆盖字段值异常

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

可能的原因

实体类未设置 setter/getter 方法。
可能存在嵌套的属性。

排查和解决步骤

检查实体类并设置 setter/getter 方法。
根据堆栈信息，检查是否使用嵌套注解。

0-25 - 加载映射错误

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

可能的原因

文件访问权限不足

排查和解决步骤

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

0-26 - 元数据发布服务时的警告信息

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

可能的原因

元数据在存储接口与应用的映射关系时，显示的提醒类消息。

排查和解决步骤

一般可根据堆栈信息进行分析，也可不处理。

0-27 - 线程池隔离配置异常

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

可能的原因

未开启应用的线程池隔离能力，但是却在 ServiceConfig 中配置了隔离的线程池信息。

排查和解决步骤

配置开启应用的线程池隔离能力：dubbo.application.executor-management-mode=isolation

0-28 - 操作了可能会引起危险的行为

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

可能的原因

你执行了以下操作之一：

尝试或已经调整了 accesslog 的输出位置

排查和解决步骤

请检查应用配置中的 accesslog.fixed.path=true 开关是否处于开启状态，如未开启则可忽略；如果当前是开启状态，则请确认是否 acesslog 路径切换的行为是否为可信任的人所执行，以避免可能的安全风险。

0-29 - 未找到Tracer依赖

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

可能的原因

你已在配置文件中开启了tracing，但未找到Tracer依赖。

目前Tracer支持两种，OpenTelemetry和Brave。

排查和解决步骤

选择一个Tracer依赖到你的项目中：


<dependency>
 <groupId>io.micrometer</groupId>
 <artifactId>micrometer-tracing-bridge-otel</artifactId>
 <optional>true</optional>
</dependency>


<dependency>
 <groupId>io.micrometer</groupId>
 <artifactId>micrometer-tracing-bridge-brave</artifactId>
 <optional>true</optional>
</dependency>

0-99 - 调用了过时 (Deprecated) 的方法

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

可能的原因

用户调用了过时 (Deprecated) 的方法。

排查和解决步骤

检查用户代码有没有调用了什么在目前所用的版本声明为 @Deprecated 的方法，如果有则按照其对应方法替代，如无则忽略即可。