Payara/Glassfish服务器WAR包重部署崩溃报错问题咨询

Payara 5.x、GlassFish 5.x在Windows环境下的重部署异常是非常普遍的已知问题，和你描述的现象完全一致：同domain下其他应用重部署正常，目标应用首次部署运行无问题，触发重部署时流程崩溃、尝试删除应用目录失败，server.log仅打印应用路径无完整异常栈，必须手动清理所有临时生成的应用相关文件才能重新部署。

• 调整日志级别输出全量堆栈：登录Payara管理后台，进入Configurations > server-config > Logger Settings > Log Levels，将以下模块的日志级别修改为FINEST后保存配置：
  • javax.enterprise.system.core
  • javax.enterprise.system.tools.deployment
  • org.glassfish.deployment
  • org.glassfish.internal.data
  • com.sun.enterprise.v3.server
    再次触发重部署操作后，server.log会打印完整的异常调用链，明确文件操作失败的具体位置。
• 开启部署流程追踪：打开domain配置文件domain.xml，在java-config节点下新增两个JVM参数：

  <jvm-options>-Dclassloader.debug=true</jvm-options>
  <jvm-options>-Dorg.glassfish.deployment.trace=true</jvm-options>
  

  重启domain后再执行重部署，日志会输出类卸载、资源释放的全流程记录，可以定位到未释放的文件句柄来源。
• 排查系统层面的文件锁：重部署失败后不要清理文件，Windows环境下直接打开系统自带的「资源监视器」，切换到CPU tab，在「关联句柄」搜索框输入应用名SAG-1.0，即可直接查到是哪个进程锁定了应用目录下的文件，导致删除操作失败。

• 路径被同步进程占用：从你给出的日志路径看，Payara安装在Dropbox同步目录下，这是该类问题最高发的触发场景。重部署时Payara会先删除旧版本应用目录，此时如果Dropbox正在同步该目录下的文件，会自动给文件加排他锁，导致Payara的删除操作直接中断，后续异常打印逻辑因为目录状态异常无法执行，就只会留下两行仅含路径的日志。直接把Payara整个安装目录移出Dropbox、OneDrive这类实时同步盘，放到本地非同步目录运行即可解决该类问题。
• 应用资源未正确释放：如果两个近似应用存在配置差异，问题应用里自定义了线程池、启动了定时任务、存在未关闭的文件流/网络连接/JDBC连接，且没有在应用卸载生命周期里显式释放，会持续持有应用内的类文件、配置文件句柄，导致重部署时旧应用文件无法被清理。可以在应用中实现ServletContextListener接口，在contextDestroyed方法里显式关闭所有自定义启动的资源。
• 版本固有bug：Payara 5.2022.2版本存在Windows环境下重部署时CDI、JSF组件持有静态资源文件锁的已知问题，临时规避可以在部署应用时添加参数--keepstate=false关闭应用状态保留，或者直接升级到Payara 5.2022.5及之后的修复版本。
• 无需全量删文件的重部署技巧：重部署前先执行应用的disable操作，等待5秒左右待所有请求处理完成、资源释放，再执行undeploy操作，最后部署新版本，基本可以避免文件锁导致的部署崩溃问题。

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