a4363220

补充说明，我的物理机原本是32g内存，升级到64g内存然后进行了重启之后，再次启动就出现了上述问题，百般无奈之下我将有关rocketmq的数据文件全部删除，再次尝试启动broker居然启动成功了，我是采取dledger模式进行运行的，是源于我升级物理机配置重启时导致rocketmq日志文件损坏？

> > 补充说明，我的物理机原本是32g内存，升级到64g内存然后进行了重启之后，再次启动就出现了上述问题，百般无奈之下我将有关rocketmq的数据文件全部删除，再次尝试启动broker居然启动成功了，我是采取dledger模式进行运行的，是源于我升级物理机配置重启时导致rocketmq日志文件损坏？ > > how about use jdk1.8? you can see this issue #4161 您好，切换到1.8我没有尝试过，或许是可以解决此问题，但是我想了解的是，4.9.4这个版本是目前对jdk11的支持还不成熟么？ 期间我还发现了一个问题，当我用dledger模式启动出现上述错误时，我尝试运行普通单机的broker时，也是能够正常启动的， 这个就让我有些不解了。

碰到同样这种问题的朋友，也麻烦指教一下解决方案，多谢了，实在没有妥善的处置方式，只能退回dubbo协议来使用了。 就我看到的issues，貌似方案2的形式也不能根本解决问题，在同一个实现方法中调用不同的provider接口好像更拿不到code和msg，不过这点我没有再深入研究了，只是有此疑问，更想得到最妥善的处理方式，多谢

> 方案三无问题一直都是这么用的 可以自己看源码 自己声明的异常不进行包装处理 public void hello()throws BizException , 这种形式还需要将异常包装？

> tri 协议目前暂不支持抛出异常，下个版本将正式支持抛自定义异常。 您好 下个版本大概预计什么时间上线呀？

> > > tri 协议目前暂不支持抛出异常，下个版本将正式支持抛自定义异常。 > > > > > > 您好 下个版本大概预计什么时间上线呀？ > > 下个月底会正式发布 好的

我在消费者方没有进行任何配置

您说的在consumer配置负载和retries应该是进入dubbo3之后才开始调整的吧？我之前一直用的2.7+版本一直是在provider中配置的cluster和retries完全没有问题。 如果provider不建议配置的话，应当尽早将属性@Deprecated话。 > retry 是一个客户端行为，不会受服务端的配置所影响。 > > 背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。

> retry 是一个客户端行为，不会受服务端的配置所影响。 > > 背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。 还有一个点，我这边在provider配置timeout经过测试是有效的，consumer没有进行配置。 那么基于您阐述的这个思路，如果一个服务端timeout设置为10秒，一个设置为20秒，那客户端怎么生效

> timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的 > > timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。 谢谢，收获良多