1.4  Portal 6.1.0.3在Windows平臺上安裝或升級失敗

1.4.1  問題描述

已經安裝了Portal 6.1.0.1或者6.1.0.2，試圖升級到6.1.0.3，發現在Windows平臺上升級失敗。

檢查升級日誌，例如20100122_135338_WP_PTF_6103_selective-install.log檔案，發現與PeopleFinder有關，是系統在安裝peoplefinder_portlet期間發生錯誤導致的，這個錯誤幾乎在portal的每個版本中都曾經出現過，如圖1-19所示。

圖1-19  PeopleFinder導致了安裝失敗

檢查people_finder portlet install日誌，例如20100122_135338_WP_PTF_6103_people.impl_._ peoplefinder_._portlet_install.log檔案，發現是由FilenotFound例外帶著的，這是由於PeopleFinder少配置了屬性。此問題雖然2011年才被發現，但我們從歷史日誌中看到，這個問題早在2009年就出現了，如圖1-20所示。

圖1-20  這個異常說明PeopleFinder有屬性丟失

這是由於安裝過程中兩個檔案的屬性被定義成了只讀屬性，無法取代導致的。可以肯定的是，系統安裝完成後，沒有手工去改過這兩個檔案的屬性，懷疑是在系統升級時，升級程式篡改了檔案屬性。

1.4.2  解決方案

登入Portal 6.1.0.3系統，找到路徑：D:\IBM\WebSphere\PortalServer\pcc.impl\people.impl\ peoplefinder\portlet\lwp_peoplefinder_war.ear\lwp.peoplefinder.jsr168.war\html\，檢視help資料夾的許可權，發現果然是隻讀的，如圖1-21所示。

圖1-21  help資料夾具有隻讀屬性

修改該資料夾屬性，確保該資料夾及子檔案、子資料夾不具有隻讀屬性。

重新安裝補丁包，安裝成功，系統成功升級到6.1.0.3。

1.5  使用WAS 6動態快取機制提高WCM Content View Portlet效能及響應速度

1.5.1  問題描述

WCM模組的速度之慢是眾所周知的。除了保證業務邏輯上的連貫性之外，使用Cache技術也是提高WCM內容展示的一個好思路。

假設我們使用WCM authory構建了有100多個站點區域的站點，然後自己開發Content View Portlet，依據引數分別將這100多個站點區域展示到100多個欄目。

接下來，我們將採用適當的WAS 6 動態快取（WAS 6 Dynomic Cache）機制來提高WCM Content View的效能及響應速度，這是充分利用Portal 6.1所使用的JSR286容器優勢的一個絕佳方法。

1.5.2  WAS 6 動態快取解決方案

在開發好的Portlet中建立 cachespec.xml 檔案來定義動態快取，如圖1-22所示。

圖1-22  在Portlet配置檔案中啟用基於WAS動態快取的技術提升效能

建立一個JavaBean來生成合理的CacheID，如圖1-23所示。

圖1-23  動態快取實現的JavaBean程式碼

 安裝該Portlet並重新測試，驗證快取是否起效。

1.5.3  使用同一個使用者ID在同一臺機器或多臺機器上同時登入會導致系統錯誤

系統測試尤其是執行壓力測試時，使用者往往無法提供併發數要求數量的真實使用者名稱和密碼，例如上面的例子，我們需要使用者提供936個真實使用者的使用者名稱和密碼，而這通常是不現實的。很多專案組就決定使用其中的50對或者100對使用者名稱/密碼模擬真實的936個使用者，實質上這是不允許的。

IBM WebSphere Portal嚴格禁止同一ID同時多次登入系統，不管是在同一臺機器上還是模擬出多個IP地址，這將會導致不可預知的後果，甚至系統崩潰，如圖1-24所示。

圖1-24  Portal資訊中心明令禁止同一ID多次登入

  對應中文的資訊中心也對該問題有明確的定義，如圖1-25所示。

圖1-25  對應中文的資訊中心對禁止同-ID多次登入也有明確的定義