Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

长轮询报 Invalid timestamp #3652

Closed
3 tasks done
sheng-jie opened this issue Apr 28, 2021 · 13 comments
Closed
3 tasks done

长轮询报 Invalid timestamp #3652

sheng-jie opened this issue Apr 28, 2021 · 13 comments
Labels
area/client apollo-client area/configservice apollo-configservice kind/report-problem Categorizes issue when someone report the problem he/she meeted status/fixed issue fixed already

Comments

@sheng-jie
Copy link

描述bug

基于最新的Helm Chart(1.8.1)部署Apollo,有指定basepath,从目前的抓包结果看,定时拉取正常,但长轮询不成功,报401,Config-Service 报Invalid timestamp。分析日志发现,日志记录时间和请求头携带的时间戳刚好相差1分钟。

有检查客户端和服务端的时区设置,均为GTM+8。

客户端使用:dotnet core sdk: Com.Ctrip.Framework.Apollo.Configuration(2.4.1)

@klboke
Copy link
Contributor

klboke commented Apr 28, 2021

检查下长轮询时候的接口地址,是不是直连走负载代理了,而不是连接的服务发现的ip

@nobodyiam
Copy link
Member

感觉上是客户端和服务端的时间不一致吧,等到机器上看下两边的时间是否就是差了 1 分钟?

@sheng-jie
Copy link
Author

sheng-jie commented Apr 29, 2021

感觉上是客户端和服务端的时间不一致吧,等到机器上看下两边的时间是否就是差了 1 分钟?

这个问题确认过了,客户端和服务端部署在同一个k8s集群里,时间一致。
另如果时间不一致,那么定时拉取鉴权也应失败。

@sheng-jie
Copy link
Author

检查下长轮询时候的接口地址,是不是直连走负载代理了,而不是连接的服务发现的ip

是的,先走负载均衡,再通过K8S的Ingress转发到对应的Config-Service。

奇怪的是,定时拉取正常,说明负载均衡正常转发,长轮询401,说明请求也正常转发。
感觉长轮询的请求被网络劫持了一分钟一样。😂

@klboke
Copy link
Contributor

klboke commented Apr 29, 2021

检查下长轮询时候的接口地址,是不是直连走负载代理了,而不是连接的服务发现的ip

是的,先走负载均衡,再通过K8S的Ingress转发到对应的Config-Service。

奇怪的是,定时拉取正常,说明负载均衡正常转发,长轮询401,说明请求也正常转发。

感觉长轮询的请求被网络劫持了一分钟一样。😂

我们遇到了和你一模一样的情况,通过ingress 转发的会 401,但是客户端按理说通过服务发现直接连接 ip 的啊,就是说长轮询的时候根本不会走ingress 代理

@klboke
Copy link
Contributor

klboke commented Apr 29, 2021

忘记你是dotnet core sdk,好像这个客户端只有直连模式

@klboke
Copy link
Contributor

klboke commented Apr 29, 2021

@sheng-jie 嗨,我这边在 ingress 这里有新发现了,你检查下你的 ingress 的这个配置目前配置的是多少 worker-shutdown-timeout 。如果小于等于 60s,就将这个值调大一点在试试呢

@sheng-jie
Copy link
Author

@klboke 谢谢跟进,目前我们采用的是traefik ingress controller,无相关配置。我在研究下dotnet core sdk,看有无线索。

@klboke
Copy link
Contributor

klboke commented Apr 29, 2021

traefik ingress controller 有没类似的配置,会影响长轮询的请求呢?响应的是长轮询,首次获取配置其实不影响,上面那个配置参数我可能理解错误了,可以先忽略。sdk 测主要是因为没有实现服务发现,长轮询 /notifications/v2 也走的代理导致,如果有服务发现得话,长轮询应该直接连接的 config service 服务

@Anilople Anilople added area/client apollo-client area/configservice apollo-configservice kind/report-problem Categorizes issue when someone report the problem he/she meeted labels Apr 29, 2021
@klboke
Copy link
Contributor

klboke commented Apr 29, 2021

已定位并确认是 nginx-ingress 的默认配置:
proxy-stream-next-upstream-tries:3
proxy-read-timeout: 60
导致的问题,造成的现象也和上面描述的吻合。ingress 60s超时,然后发起重试,apollo 判断签名失败返回 401 。将 proxy-read-timeout 设置为 90s,大于 apollo 长轮询的 60s 超时即可。

@zouyx
Copy link
Member

zouyx commented May 5, 2021

已定位并确认是 nginx-ingress 的默认配置:
proxy-stream-next-upstream-tries:3
proxy-read-timeout: 60
导致的问题,造成的现象也和上面描述的吻合。ingress 60s超时,然后发起重试,apollo 判断签名失败返回 401 。将 proxy-read-timeout 设置为 90s,大于 apollo 长轮询的 60s 超时即可。

very good

@sheng-jie
Copy link
Author

@klboke 感谢,的确如此,开始我们以为是traefik-ingress的问题,但未发现相关配置项。最后分析是我们还有一层CLB,将相关参数调整后,测试正常。再次感谢!

@Anilople Anilople added the status/fixed issue fixed already label May 7, 2021
@lai-vson
Copy link

lai-vson commented Mar 7, 2025

@klboke 感谢,的确如此,开始我们以为是traefik-ingress的问题,但未发现相关配置项。最后分析是我们还有一层CLB,将相关参数调整后,测试正常。再次感谢!

能请问一下, 改动的是CLB里哪个参数吗?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/client apollo-client area/configservice apollo-configservice kind/report-problem Categorizes issue when someone report the problem he/she meeted status/fixed issue fixed already
Projects
None yet
Development

No branches or pull requests

6 participants