在调试我们的网络应用程序时，我们发现我们的JBOSS群集返回的.js / .css / etc静态文件的“Last-Modified”时间戳在两个不同的值之间波动 - 这也是我们JBOSS集群中的节点数量（我们有两台机器，每台机器在集群节点配置中运行JBOSS实例）。然后我们验证了每个JBOSS节点确实提供了不同的时间戳（对于特定的请求资源，例如/some/resource.js），这不是 APPNAME.war中存在的文件的修改时间戳
进一步搜索显示，当我们的.ear的新版本部署到群集时，两个JBOSS实例在自动命名的文件夹中解压缩它（例如... / deployment4670b6dc3fccdb52 / APPNAME-war-885ea865da6056a5 /）。在这些文件夹中，我们检查并验证它是用于“Last-Modified”HTTP标头响应的新未压缩文件的修改时间戳，并且这些时间戳确实不是包含在其中的实际修改时间戳。的.war 即可。事实上，看起来JBOSS在解压缩这些文件时正在使用部署时间 - 这意味着它使用“.war解压缩期间的当前时间”，并且每个JBOSS实例最终都有自己的时间戳本地“版本”。
反过来意味着， JBOSS群集为客户端提供了不同的“Last-Modified”时间戳，用于静态资源，具体取决于JBOSS集群IP转发它们的服务器！由于我们的群集是基于循环配置的，这意味着我们客户的浏览器可以看到如下所示的“Last-Modified”标头：
... T1和T2有两个完全不同的时间戳（.war在两个簇节点中的每个节点都未压缩的时间）。
最后，这似乎完全弄乱了浏览器的缓存簿记。更具体地说，浏览器最终会重新下载内容 - 这确实非常浪费。
为什么JBOSS不使用.ear中包含的时间戳而是使用“deploy-decompression-time”？我验证了使用“jar xvf”从.ear中提取.war，再次在.war上提取“jar xvf”，时间戳是正确的（机器中的时间戳正在进行构建）。时间戳信息就在.ear / .war中 - 它似乎被JBOSS忽略了。
到目前为止我们使用的解决方法是停止群集中的两个节点之一，从而强制“一致”时间戳（错误的时间，请注意 - 因为它们是仍在运行的节点的“部署时间” - 但至少它们在对同一资源的重复HTTP请求中保持一致。
欢迎任何帮助。
答案 0 :(得分：0)
原来这是JBOSS EAP 6.0中的一个错误，已在以后的版本中修复。