最近一個項目中的Cognos老報“asynchWait_Request”，請查找，發現如下文章可解決問題，就轉了過來。
絕對親和力是什麼？
親和力連接：親和力連接用來請求，它是報表服務進程（BIBusTKServerMain）一部分（可以理解爲線程）。親和力根據一個請求是否分配給特定的服務還是分佈式環境中可以分配給另外一個服務。親和力在請求和服務之間，它負責確保請求會被傳遞到合適的服務器上去執行。親和力請求類型分爲三種：絕對親和力、高親和力、低親和力。
絕對親和力請求：每個報表進程中除了高親和力請求和低親和力請求，還有絕對親和力請求。絕對親和力請求只能在特定的報表服務上執行，不管是否有負載均衡。取消報表操作是最好的例子，只有在運行報表的服務上才能取消它。絕對親和力請求就像他的名字-絕對存在（By its very nature, absolute affinity requests are just that – absolute），因此針對此類請求的參數沒有包含在ReportNet參數中以免冗餘。絕對親和力請求負責爲客戶端和服務器創建關聯，以確保長時間運行的報表不會超時。絕對親和力請求在下面的操作中會用到：等待、獲取輸出、釋放。例子：當用戶取消一個正在運行的報表時，絕對親和力連接負責將取消請求傳遞給運行報表所在進程。
低親和力請求：低親和力請求在任意報表進程中都能以同樣的效率完全執行。低親和力請求是獨立的，在系統處理過程中與其他請求沒有任何關聯。低親和力請求包括PDF、HTML報表的第一頁。報表：報表查詢、報表處理；報表認證：元數據檢索、查詢驗證；管理：測試數據源、添加對象（文件夾、job、計劃任務等等）、請求門戶頁面；
問題產生的背景：
最近公司一個項目搞驗收，系統是基於B/S架構，採用了IBM Cognos 10；最近一段時間老是反饋報表打不開，具體錯誤如下：
Original Error: RSV-BBP-0022 絕對親和力請求“asynchWait_Request”失敗，所請求的會話不存在。 RSV-SRV-0042 回溯： RSReportService.cpp(792): RSException: CCL_CAUGHT: RSReportService::process() RSReportServiceMethod.cpp(241): RSException: CCL_RETHROW: RSReportServiceMethod::process(): asynchWait_Request RSReportServiceHelper.cpp(831): RSException: CCL_THROW: RSReportServiceHelper::absoluteAffinityError()
如圖所示：
公司的負責這塊技術的同事長時間未解決該問題，也通過搜索網上類似解決辦法，均未成功解決；現場項目經理打我電話說用戶因爲這個問題的存在不肯簽字確認功能，影響系統驗收進度。
我根據這個問題的現象反饋，找到現場的同事遠程檢查服務器配置環境和參數，結合網上提供的優化配置方法進行設置，折騰了1個多小時，發現現象依舊；
主要問題現象表現爲：
在系統內打開報表的時候，經常提升asynchWait_Request錯誤信息，參見上圖；
如果關閉瀏覽器再次打開可能就正常；
如果用非IE瀏覽器打開基本都正常；
如果直接用Cognos的報表URL地址打開就正常；
在Cognos服務器上打開正常；
這個問題非常的奇怪，唯獨用IE，在系統內打開報表就出這樣的問題，莫非是技術上存在問題？但是之前的每個項目都是採用同樣的技術集成報表頁面，幾乎不存在這個問題出現，偶爾出現過，都通過修改系統的配置最後解決掉了。
既然配置可以解決，那麼馬上找出Cognos的優化設置的文檔進行參考，
現場的Cognos服務器是IBM的X3850，4顆物理CPU，48核心，16G內存，從性能上來說，可配置的空間很大，打開Cognos的服務設置頁面，根據IBM的建議，對進程數進行了設置。
還根據百度的文檔（可單擊訪問）對ReportService進行了多方面的參數設置。但是現象依舊存在！而且現象和之前並無差別！證明設置未影響任何內容，也可能優化了性能，但感覺不出，因爲之前的報表每個響應成功的話，都是3秒內顯示的，故不明顯！既然沒有解決問題，只能尋求其他的解決途徑，經過本人的分析，認爲網絡也有可能存在問題；
目前系統的網絡情況如下：
Cognos服務器IP是1.x.x.7
應用服務器的IP是1.x.x.6
客戶機的IP是2.x.x.x
簡單的來說，客戶機和服務器並非同一個網段；爲了檢查網絡情況，開啓了多個工具軟件，檢查Cognos服務器的網絡健康情況，發現一切正常。
既然網絡無問題，經過思考後，再重新檢查問題現象，考慮到如果是單獨新開瀏覽器訪問地址就不報錯，並且不用IE也不報錯，那麼會不是IE的Bug？考慮到以前開發B/S系統的經驗，那時候發現iframe會導致Session丟失，會不會是這個原因？
根據分析提供的解決辦法：
在客戶機的IE菜單中選擇[工具]à[Internet選項]，出現如下窗口：
將Cognos服務器的IP地址輸入進去
關閉，並重新打開系統內的報表
隨意訪問各個報表，無論多次操作，均不再報親和力錯誤；
至此，問題已經解決，只需要項目經理安排運維人員把客戶機的設置配置好，並且更新下用戶手冊中的描述；特別提醒：一定要寫入”本地Intranet“，並不是放入”受信任站點”。
在寫本文之前，網絡上有太多的人搜索”Cognos 絕對親和力異常”的問題和相似的處理辦法，基本上都是不了了之，也不知是否真正解決問題，解決思路都是說進行系統配置之類的，個別提出了在iframe內出錯的線索，也未被深究，問題也未得到解決；竟然還有人以’經驗’之談歸結於Cognos的Bug，此等Bug是否可以定位爲Bug我也不清楚，但解決問題必須要有發散性思維，多多嘗試，不要忽視周邊的因素而信口開河；認爲錯誤既然是Cognos報的，那鐵定就是它有’問題’了！
原文地址：