ZongZihao commented on issue #9518: URL: https://github.com/apache/rocketmq/issues/9518#issuecomment-3555618009
> > > 根因： > > > > > > 1. pop接口要求传递bornTime， 在存算分离架构里面，这个bornTime为了防止proxy和broker的机器出现时钟偏差，所以没有传，让broker自己设置，但是broker上设置的是RemotingCommand#extFields这个值。 > > > 2. 当开启ACL2.0的时候，为了能够获取到POP请求的参数，会提前进行一次deocde，这会导致RemotingCommand#cachedHeader已经缓存了旧值，因此上面的设置是无效的 > > > 3. 消费消息的时候，由于这个bornTime没有正确设置，服务端在计算`System.currentTimeMillis() - bornTime - pollTime > 500`的永远返回true， 就报"the broker[%s] pop message is timeout too much"这个异常，一直拉不到消息 > > > > > > 修复方法： bornTime的设置基于decode之后的对象进行设置 > > > > > > > ，你们是怎么访问的，客户端访问的proxy吗，还是broker, 然后用的是remoting客户端还 > > > > > > proxy和broker分离部署，使用gRPC访问proxy， 可以正常发送消息，消息时无法获取消息（POP方式），客户端和服务端proxy，broker均无异常日志。 还有个前提是开启ACL2.0，使用ACL1.0就没有这个问题。 我看到你提的修复了，应该就是bronTime的问题，我纳闷的是这应该是一个影响极大的BUG，尤其是5.3.3只能使用acl2.0的版本，结果反映的人却寥寥无几，官方也没有回应。 > > 1. 大部分的用户，在部署proxy之后，broker不会开启ACL，所以不会有这个问题。 > 2. 最开始发布ACL2.0的时候的版本都是没问题的，后面他们改pop相关逻辑没考虑这个场景 可能大部分人都是内网自己的服务在使用，所以不需要权限控制了。 关键这个acl2.0到现在官方都没有给一个详细的可用文档出来。 还有同问一下proxy开启acl之后， broker就不用开启了么？ 这个我好像没有尝试过 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
