portal開發與配置技巧集錦（二）

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有屬性丟失

這是由于安裝過程中兩個文件的屬性被定義成了只讀屬性，無法取代導致的。可以肯定的是，系統安裝完成后，沒有手工去改過這兩個文件的屬性，懷疑是在系統升級時，升級程序篡改了文件屬性。6.1.0.3升級程序剛剛推出沒多久，出現這種可能的錯誤也是正常的。

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多次登錄也有明確的定義