http://***/notifications/v2?cluster=default&appId=******

[xujieli1]

源码里面这个方法解析我不是很明白，为什么要用小于号
com.ctrip.framework.apollo.configservice.controller.NotificationControllerV2#filterNotifications 203行

根据我传入的notificationId去获取配置列表，为什么要用小于号，导致我传入相等的也获取不到

[nobodyiam]

这一段是用来处理 namespace 大小写不一致的场景的，具体逻辑可以参考上述的注释。

根据我传入的notificationId去获取配置列表，为什么要用小于号，导致我传入相等的也获取不到

你是自己写了客户端吗？可以尝试debug一下代码，看描述应该和这段逻辑没关系

[xujieli1]

【自己没有写客户端】我的报错就是一只提示：Long polling failed, will retry in ** seconds. 我看到客户端代码逻辑是：从这个链接去获取，如果返回200或304是正常的，否则就是不行。本地不会有这个报错，但是测试环境一直有这个warn日志提示，不知道是什么原因，然后尝试改了一下这个notificationId，发现就OK了能获取到。

[xujieli1]

#3246 我的报错和这个报错一样的，http://apolloconfig.dev.xisland.cn 这个域名是config-service的域名

[hulucc]

我也遇到这个问题了，用比较大的notificationId，config svc就卡住不回复了，会504。
我可以用curl调用链接重现，所以和客户端无关。我可以绕过所有load balancer, 中间件，直接用curl localhost:8080 对服务本身调用，也能重现，所以也排除了链路异常导致的超时。
调用的时候config svc不会有日志报错

[nobodyiam]

@hulucc apollo 不会返回 504 的，应该是你中间的 lb 超时时间配置的小了，可以尝试调大一些。如果调不了 lb 的超时时间，可以把 apollo long polling 的时间调短，参考 #2532

[hulucc]

@hulucc apollo 不会返回 504 的，应该是你中间的 lb 超时时间配置的小了，可以尝试调大一些。如果调不了 lb 的超时时间，可以把 apollo long polling 的时间调短，参考 #2532

其他遇到这个问题的同学可以同步一个认知，notification 的 http 请求有个设定是需要hold住60秒的，而并非我之前理解的每60秒去查一次或者走websocket之类的。
这种把短连接当长连接用的方法在很多中间件都会有问题，比如nginx，阿里云的slb等。
服务端改短可以配置环境变量 LONG_POLLING_TIMEOUT
helm:

env:
  LONG_POLLING_TIMEOUT: '"10"'

nginx ingress的话:

annotations:
  nginx.ingress.kubernetes.io/proxy-read-timeout: "120"

slb对于这种请求似乎是会认为是死链接，经过一个内置的超时后就直接掐了，有人知道如何配置的话请赐教

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in 14 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 7 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.