Websphere Liberty Profile 17.0.0.1上JSF 2.2应用会话间歇性快速过期问题

我碰到过不少类似的Liberty会话超时异常情况，结合你的配置描述和症状，给你几个针对性的排查方向：

1. 先检查Web应用自身的web.xml会话配置 #

WebSphere Liberty里，应用本地的web.xml配置优先级会高于server.xml的全局httpSession设置。如果你的应用web.xml里有如下配置，会直接覆盖你在server.xml中设置的15分钟超时：

<session-config>
    <session-timeout>1</session-timeout> <!-- 这里设置了1分钟，会强制生效 -->
</session-config>

先确认web.xml里有没有这个配置，有的话修改为15或者直接删除（让应用继承全局配置）。

2. 补全并验证LTPA配置的完整性 #

你提供的LTPA配置被截断了，完整的LTPA配置应该类似这样：

<ltpa expiration="15m" keysFileName="${server.config.dir}/ltpa.keys" password="yourLtpaPassword"/>

需要注意两点：

• LTPA令牌的expiration最好和会话超时保持一致（都是15m），如果LTPA令牌提前过期，会直接导致用户被强制登出，看起来就像是会话超时。
• 确保keysFileName指向的密钥文件存在且权限正常，密钥文件损坏或无法读取可能导致LTPA令牌生成异常，引发间歇性的会话失效。

3. 排查JSF视图状态与会话的交互问题 #

JSF 2.2默认把服务器端视图状态存在会话中，如果视图状态处理出现异常，可能间接触发会话提前回收：

• 检查应用是否配置了javax.faces.STATE_SAVING_METHOD为server（默认就是server），如果是客户端状态保存一般不会影响会话，但server端的话，要确认有没有自定义的视图清理逻辑误操作了会话。
• 排查@ViewScoped Bean的销毁方法里，有没有意外调用session.invalidate()的情况。

4. 检查应用代码中的手动会话失效逻辑 #

仔细排查应用的过滤器、拦截器或者业务代码，有没有以下操作：

• 调用HttpSession.invalidate()的逻辑，可能某些特定条件（比如特定请求参数、用户操作）下被触发，导致会话提前失效。
• 设置会话超时的代码，比如session.setMaxInactiveInterval(60)（60秒=1分钟），这种代码会直接覆盖全局配置。

5. 集群环境下的额外排查（如果是集群部署） #

如果你的Liberty是集群模式：

• 检查各个节点的系统时钟是否同步，时钟不一致会导致会话超时计算出现偏差，引发间歇性过期。
• 检查分布式会话的配置（比如distributedCache），确保会话复制正常，没有出现会话丢失的情况。

6. 启用会话调试日志定位根因 #

在server.xml中启用会话相关的调试日志，能帮你精准找到会话失效的触发原因：

<logging traceSpecification="com.ibm.ws.session.*=all"/>

重启服务器后，查看logs/trace.log，搜索会话创建、失效的日志条目，就能看到每次提前失效的会话是因为LTPA令牌过期、手动失效还是超时计算错误。

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