Tomcat升级后会话提前过期求助：设定2小时却2-3分钟失效

• 确认会话超时配置的实际生效逻辑
  堆栈里显示MaxInactiveInterval=7200，但得检查conf/web.xml的全局会话配置是否被应用自身的web.xml覆盖。另外，Tomcat 9.0.45到9.0.102之间，有没有系统属性、环境变量意外改写了超时时间？比如启动参数里加了-Dorg.apache.catalina.session.StandardSession.maxInactiveInterval这类配置？

• 排查应用主动销毁会话的代码
  检查所有调用session.invalidate()的地方，包括过滤器、拦截器、业务接口。升级后依赖库的行为变化，可能触发了原本没执行的失效逻辑。另外，你提供的堆栈有乱码，建议重新生成清晰的调用栈，确认是Tomcat的超时清理线程触发销毁，还是应用主动调用的。

• 核对Tomcat会话清理机制的版本差异
  Tomcat的会话管理器在这两个版本间有不少更新，重点查：

  • conf/context.xml里的<Manager>配置，processExpiresFrequency（默认6秒）控制清理线程频率，但正常不会导致7200秒超时的会话提前被清；
  • 如果用了PersistentManager做会话持久化，检查存储介质（比如文件、数据库）是否正常，有没有出现会话数据损坏导致超时判断错误；
  • 翻Tomcat官方changelog，看看9.0.45到9.0.102之间有没有会话超时计算相关的bug修复或变更，比如是否有版本存在超时时间单位错误的问题？

• 检查客户端Cookie的有效性
  确认客户端是否正确保存并携带JSESSIONID Cookie：

  • 升级后Tomcat的Cookie配置（secure、httpOnly、SameSite）有没有变化？比如突然开启了secure但网站用的是HTTP，导致Cookie无法被携带；
  • Cookie的路径、域名是否和应用匹配？如果路径不对，客户端每次请求都不带JSESSIONID，旧会话自然会因为无交互被快速销毁。

• 集群环境下的会话粘性与复制问题
  如果是集群部署：

  • 反向代理/负载均衡的会话粘性配置是否正常？如果请求被随机分发到不同节点，每个节点上的会话都会因为长时间无请求被销毁；
  • 会话复制（比如DeltaManager、BackupManager）是否正常工作？升级后如果复制机制异常，某个节点的会话数据没同步，也会被提前清理。

内容的提问来源于stack exchange，提问作者zackhalil