Migrating from Spring boot 3.5.11 to 4.0.3 : reregister-service-on-failure not working anymore
维护者通常 1 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- java, spring-boot
调研方向
首先运行附带的两个 consul-client 示例,并比较 Spring Boot 3.5.11/Spring Cloud 2025.0.1 与 Spring Boot 4.0.3/Spring Cloud 2025.1.1 的行为。跟踪 ConsulCatalogWatch 和 TtlScheduler 在 Consul agent 重启前后的情况。完成标准是:Consul 重启后,较新的示例能够重新注册服务,而无需重启应用程序。
由索引模型根据 Issue 内容生成。
描述
Describe the bug
I have a spring boot application (3.5.11) using spring-cloud-starter-consul-discovery (2025.0.1).
I have activated reregister-service-on-failure as the consul may sometimes be restarted.
That works perfectly fine.
Now I'm migrating the app to the lastest version (spring boot 4.03 ans spring cloud 2025.1.1).
Unfortunatly when I restart the consul agent, the app do not re-register anymore.
Sample
1- Here's an example with spring boot 3.5.11 and spring cloud 2025.0.1 (everything works as expected)
consul-client-3.5.9.zip
When I start the app, the service registered :
2026-03-03T15:23:40.271-10:00 INFO 15316 --- [DEMO-SERVICE] [ main] o.s.c.c.s.ConsulServiceRegistry : Registering service with consul: NewService{id='DEMO-SERVICE-9091', name='DEMO-SERVICE', tags=[], address='10.0.10.5', meta={secure=false}, port=9091, enableTagOverride=null, check=Check{script='null', dockerContainerID='null', shell='null', interval='null', ttl='30s', http='null', method='null', header=null, tcp='null', timeout='null', deregisterCriticalServiceAfter='null', tlsSkipVerify=null, status='null', grpc='null', grpcUseTLS=null}, checks=null}
When I stop the consul agent:
2026-03-03T15:24:39.807-10:00 INFO 9560 --- [DEMO-SERVICE] [TaskScheduler-1] o.apache.http.impl.execchain.RetryExec : I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {}->http://localhost:8500: The target server failed to respond
2026-03-03T15:24:39.807-10:00 INFO 9560 --- [DEMO-SERVICE] [TaskScheduler-1] o.apache.http.impl.execchain.RetryExec : Retrying request to {}->http://localhost:8500
2026-03-03T15:24:39.821-10:00 ERROR 9560 --- [DEMO-SERVICE] [TaskScheduler-1] o.s.c.c.discovery.ConsulCatalogWatch : Error watching Consul CatalogServices
com.ecwid.consul.transport.TransportException: org.apache.http.conn.HttpHostConnectException: Connect to localhost:8500 [localhost/127.0.0.1,
...
Caused by: java.net.ConnectException: Connection refused: getsockopt
When I restart the consult agent, the TtlScheduler is called and the service is re-registered :
2026-03-03T15:24:47.355-10:00 WARN 9560 --- [DEMO-SERVICE] [pool-2-thread-1] o.s.cloud.consul.discovery.TtlScheduler : OperationException(statusCode=404, statusMessage='Not Found', statusContent='Unknown check ID "service:DEMO-SERVICE-9091". Ensure that the check ID is passed, not the check name.')
2026-03-03T15:24:47.355-10:00 INFO 9560 --- [DEMO-SERVICE] [pool-2-thread-1] o.s.cloud.consul.discovery.TtlScheduler : Re-register NewService{id='DEMO-SERVICE-9091', name='DEMO-SERVICE', tags=[], address='10.0.10.5', meta={secure=false}, port=9091, enableTagOverride=null, check=Check{script='null', dockerContainerID='null', shell='null', interval='null', ttl='30s', http='null', method='null', header=null, tcp='null', timeout='null', deregisterCriticalServiceAfter='null', tlsSkipVerify=null, status='null', grpc='null', grpcUseTLS=null}, checks=null}
2- Here's the same example with spring boot 4.0.3 and spring cloud 2025.1.1 (re-registering doesn't occured)
consul-client-4.0.3.zip
At startup the service is registered :
2026-03-03T15:32:08.116-10:00 INFO 17028 --- [DEMO-SERVICE] [ main] o.s.c.c.s.ConsulServiceRegistry : Registering service with consul: [NewService@1d9af731 id = 'DEMO-SERVICE-9091', name = 'DEMO-SERVICE', tags = list[[empty]], address = '10.0.10.5', meta = map['secure' -> 'false'], port = 9091, enableTagOverride = [null], check = [NewService.Check@39afe59f args = [null], dockerContainerID = [null], shell = [null], interval = [null], ttl = '30s', http = [null], method = [null], header = [null], tcp = [null], timeout = [null], deregisterCriticalServiceAfter = [null], tlsSkipVerify = [null], status = [null], grpc = [null], grpcUseTLS = [null]], checks = [null]]
When I stop the consul agent:
2026-03-03T15:33:55.550-10:00 ERROR 17028 --- [DEMO-SERVICE] [TaskScheduler-1] o.s.c.c.discovery.ConsulCatalogWatch : Error watching Consul CatalogServices
org.springframework.web.client.ResourceAccessException: I/O error on GET request for "http://localhost:8500/v1/catalog/services": null
When I restart the consult agent, nothing happens (no log, no re-register). I have to restart the application.
- 主要语言
- Java
- 星标
- 821
- 派生
- 540
- 平均合并
- 13 小时 41 分钟
- 30 天内合并 PR
- 17
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
spring-cloud/spring-cloud-consul 的其他 Issue
-
waiting-for-triage
难度 2/5 1-3 小时 新手友好度 68/100
spring-cloud/spring-cloud-consul#984 ·
维护者通常 1 天内回复
-
waiting-for-triage
难度 4/5 3-5 天 新手友好度 45/100
spring-cloud/spring-cloud-consul#996 · 1 条评论 ·
维护者通常 1 天内回复
-
waiting-for-triage
难度 3/5 1-2 天 新手友好度 52/100
spring-cloud/spring-cloud-consul#951 · 4 条评论 ·
维护者通常 1 天内回复
-
waiting-for-triage
难度 4/5 3-5 天 新手友好度 45/100
spring-cloud/spring-cloud-consul#950 · 4 条评论 ·
维护者通常 1 天内回复
-
waiting-for-triage
难度 3/5 1-2 天 新手友好度 45/100
spring-cloud/spring-cloud-consul#948 · 1 个 reaction ·
维护者通常 1 天内回复
查看 spring-cloud/spring-cloud-consul 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
EpssMirrorTask leaks temp file on failed download and has no request timeout可能已有人在做 @someshhh-45 今天认领。 未关闭defect in triage
难度 2/5 1-3 小时 新手友好度 78/100
DependencyTrack/dependency-track#7845 ·
维护者通常 1 天内回复
-
[Bug]: WriteFileTool shows "Error reading file" snippet for relative paths when baseDir is set可能已有人在做 @ShryukGrandhi 今天认领。 未关闭
难度 2/5 1 小时以内 新手友好度 86/100
agentscope-ai/agentscope-java#3917 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 78/100
apache/maven-checkstyle-plugin#735 ·
维护者通常 1 天内回复