URLRewrite 規則隨機未加載 - Intershop 7.10.29.2

Question

EDIT1： intershop.urlrewrite.CheckSource 已關閉

我們最近在測試和生產多節點環境中沒有加載 URL 重寫規則時遇到了很大的問題。 在將另一個組織及其相關應用程序引入服務器后，問題開始發生。 從那時起，我們嘗試了多種更改和調試方法來試圖弄清楚，但沒有任何結果。 此外，主要問題是它不會一直發生，服務器重啟可以修復它，但並非總是如此。

以下是到目前為止問題表現的詳細信息（這在我們的生產系統上已經持續了一個多月）：

• 大多數情況下，它在部署新代碼並啟動服務器后開始發生
• 然后來自多台計算機和位置的多個人嘗試打開該網站，一些人打開它，其他人得到 404 或“URL 無效”頁面，因此它是 50/50。
• 在有人成功打開頁面的 PC 上，如果您在隱身模式下再次嘗試，那么您可能會再次收到 404（可能連接到另一個節點/應用服務器）。
• 通常通過服務器重啟或重啟單個節點（沒有代碼或配置更改）來解決問題，盡管這不是可靠的方法，並且在最后一次出現時，我們嘗試了多次重啟，但沒有幫助。 幾天后，其中一名團隊成員僅出於調試目的重新啟動了一個節點，然后它又開始正常工作。

在為 URL 重寫類設置更詳細的日志消息並打開調試消息之后，我們得出的結論是規則加載失敗。 我們得出這個結論是因為我們在 applyExpand() 方法的一開始就添加了調試消息，但它從未顯示出來。 這可以在下圖中觀察到： 所有這些都導致第 149 行的迭代器是空的。

請告知此問題的可能原因以及如何解決。

Answer 1

實現了規則加載，因此可以即時編輯/添加/刪除規則，而無需重新啟動 Web 服務器。 當屬性intershop.urlrewrite.CheckSource設置為true時會發生這種情況。 為此，將評估文件的最后修改時間。 也許這不能正常工作。

如果問題仍然存在，我建議將此屬性設置為false並再次測試。

Answer 2

在 IS 支持的幫助下，我們設法找出問題在於 URL 重寫規則位於一個卡式磁帶中，該卡式不是服務器上每個可能的應用程序的一部分，這會在加載它們時導致未定義的行為（它會加載在一個應用程序服務器上，而在另一個應用程序服務器上則不會）。

解決方法是為所有可能的應用程序添加一個新的通用盒，然后這些應用程序將保存 urlrewrite 規則，並且肯定會在服務器啟動時加載。