 us9929
|
80b82121a1
|
加固下载服务与删除路径，补测试
- 8888 下载服务：加读超时、接受循环单次失败不退出；畸形请求行回 400 且不泄漏连接；
Range 越界按文件末端夹取或回 416，非法 Range 不再中断处理
- 删除任务改为按根目录规范化校验，拦截 ../ 与绝对路径越界删除
- MessageCodec：先序列化再写帧头（不再产生半帧），并限制单帧长度上限
- 节点绑定端口等待结果，失败即抛出而非静默不监听
- 配置加载支持指定路径并对缺文件记录告警；完成通知对消息做 URL 编码并加超时
- 测试 28 → 76：新增协议编解码、节点消息处理与上报循环、备机订阅分发、
gid 匹配、删除边界、配置加载等用例
|
2026-09-23 01:04:03 +08:00 |
|
|
root
|
77f817d402
|
修复主站通道引用被误清空导致任务状态永久卡住
问题：主站重连期间节点先后认证多条通道，引用被最后一条覆盖；那条通道断开后
引用被清空，而更早建立、仍然可用的通道继续发送可用性探测。节点因引用为空不再
上报任何任务状态，主站又能在旧通道上收到探活响应，双方都判定连接正常。于是
未完成任务永久停在「已提交」，只有人工触发重连或重启主站才会恢复。
现场证据：gid 4203383 于 19:31 创建、19:32 归档完成，节点此后每 5 秒扫到
status=4，却再未打印过「任务状态发送完成」；主站侧 17:23 之后一条「下载进度」
都没有。20:28/20:29 两次收到任务下发时节点判定 server 为空而静默丢弃。
修复：
- 新增 PrimaryChannelTracker 统一管理主站通道引用，并保留全部已认证通道。
首选通道失效时立即回退到其它仍可用的已认证通道；引用被清空时，已认证通道上
的下一条消息即可恢复它。认领口径严格等于主站实际会发的消息类型（身份/任务下发/
删除/探活/订阅快照），备机身份与节点自身出站类型都不算证据。
- 新增 RekickPolicy：有待上报任务却无可用通道时，以 30 秒为限流间隔主动重新
唤起主站，不再干等最长半小时的探测周期。阻塞式探测投递到独立线程，避免占用
5 秒调度线程拖住下载扫描与压缩。
- 通道不可用时的告警与重连判断放在 downloadCheck 之前，但不提前返回，
本地下载与压缩必须继续推进；否则正在下载、进度无变化的任务会走「无需上报」
的提前返回路径，通道失联后既不告警也不重连，正是历史事故的成因。
验证：新增 13 项测试（通道引用自愈 6、事故场景复现 3、重连限流 4），
节点侧合计 28 项全绿。已部署到存储节点并与主站重新握手，双向报文正常，
未完成任务数归零。
|
2026-09-21 22:17:14 +08:00 |
|
|
root
|
de1e81d9b0
|
固定 Java 21 release 编译并更新项目说明
|
2026-09-14 19:17:23 +08:00 |
|
|
root
|
922e7a2a61
|
修复订阅快照校验、回退与原生反射配置
|
2026-08-30 10:34:18 +08:00 |
|
|
chuzhongzai
|
6447a74e0c
|
增加项目结构文件
|
2026-06-07 15:42:57 +08:00 |
|