在过去的几天里，已经工作了两三年的古老的Jelastic环境在无法解释的情况下失败了。它们是运行在旧Tomcat版本（7.0.57和7.0.61）上的Java / Spring应用。
在一种情况下（Tomcat 7.0.57），一些特定于Tomcat和应用程序的配置文件消失了，没有任何解释，然后Tomcat甚至在恢复丢失的文件后也拒绝重新启动。鉴于修复该生产环境的需求，我们被迫从头开始重新创建环境（Jelastic为我们提供了一个新的Tomcat 7.0.88节点。）
在第二种情况下（Tomcat 7.0.61），似乎没有丢失的Tomcat文件，但是Tomcat只是拒绝重新启动。我们尝试进行一次简单的重新启动（就像我们已经做过数百次一样），然后Tomcat只是拒绝重新启动。 Tomcat: Actions窗口显示如下：
Stopping tomcat [ OK ]
Starting tomcat [ FAILED ]
在尝试重新启动之前，我们已经清除或删除了catalina.out日志和其他文件（使用仪表板中的按钮）。然后，重新启动后，catalina.out中没有任何内容打印出来（无论是在仪表板中还是通过SSH），因此我们没有任何迹象表明可能导致Tomcat重新启动的情况。我们还尝试完全停止环境，然后重新启动，但无济于事。我们确定Tomcat不会运行，因为该节点正在消耗一个cloudlet，而正常情况下它将至少使用7。
然后，作为最后的尝试，我们尝试重新部署已保存在Deployment Manager中的WAR（几个月前，它是用于原始部署的WAR。）我们收到以下消息：
Deploy to ROOT of App. Servers (<environment name>)
"<war file>" archive can't be deployed to "ROOT" context because this archive is damaged. Please recheck the archive and try again.
缺少Tomcat和应用程序文件以及损坏的WAR文件是令人不安的信号。我们的Jelastic提供程序最近对Jelastic Platform 5.4版进行的升级是否可能导致较旧的环境出现问题？也许已经应用了一些迁移或升级过程，使旧环境处于脆弱状态？也许我的提供商的硬件出现故障？
在这一点上，我们无法理解正在发生的事情。由于担心重新启动或重新部署会破坏我们的生产环境，因此我们被迫停止在较旧的环境上更新应用程序，直到我们了解发生了什么。任何帮助表示赞赏。