Servlet 3.0和Comet/long-polling：在這些特定場景中會發生什麼？

Question

我看了一下Servlet 3.0實現服務器推送here的簡要概述，並留下了比我更多的問題。這些問題與我的使用案例有關：在Facebook的「朋友」中實施動態通知系統。從概念上思考這個問題，我想接近它像這樣：

1. 把無限的jQuery循環中的每個 頁，包含代碼發出 XMLHttpRequest的「獲取」請求 服務器
2. 允許服務器於與這些 類型的XMLHttpRequest的 請求/響應的對象存儲在一個 應用程序作用域圖（與AsyncContext和 .startAsync（）的 幫助），通過用戶的 網站ID鍵控
3. 每當用戶在產卵通知的動作 配合，查詢 應用範圍的地圖的 用戶的朋友的ID，並使用存儲在那裏的 響應對象，發送 通知給每個朋友。
4. 每個朋友收到 通知，以及他們是在問題頁無限循環 再次 的XMLHttpRequest（由於無限循環）

假設我的系統是概念上的聲音（如果它不是，請告訴我，什麼是錯的），有一對夫婦的問題，我用這個系統看到：

1. 響應之後發生的請求/響應 對地圖中的什麼 是使用d？我應該手動 從地圖中刪除，或等待 環路在客戶端發送 另一個請求，從而所存儲的 請求/響應對象對可更換用 新的XMLHttpRequest相關聯的一對 ？上面的鏈接 使用單詞「承諾」和 「未提交」參照 響應對象。有人可以解釋 這個詞的意思嗎（我有一種感覺 它們與 響應對象的長壽有關）？

2. 如果兩個或兩個以上的用戶朋友在完全相同的時間參與引發通知的操作，會發生什麼情況？每個用戶只存儲一個請求/響應對。無論朋友的行爲如何發現有問題的用戶的請求/響應對都會將其通知發送給該用戶，但其他朋友的行爲又如何呢？如果它們全部同時發生，那麼其他操作將不會有請求/響應對用於發送通知，直到用戶發送另一個XMLHttpRequest以存儲在地圖中。據推測，其他操作會解析該映射，並且找不到該用戶的條目（因爲在其他操作使用該響應之後手動刪除了該條目），或者找到已經使用的「陳舊」請求/響應對象。我假設一個響應對象不能用於兩種不同的響應，那麼有人會如何解決這個問題呢？

3. 如果通知是 發送給用戶，當用戶 切換頁面時會發生什麼？如果我們把一個完全 加載的網頁作爲一個開放的窗口 用於接收通知請求， 和裝載一個作爲一個封閉的窗口 （因爲它是無法接受和 到之前 頁面發送 XMLHttpRequest的過程反應），在此期間 期間發送的通知將會丟失。是 有什麼我可以做到的 查詢數據庫新的 行動和生成通知 頁面加載？

4. 最後，當用戶 導航離開該站點和 會話到期時會發生什麼？我們是否期望 定期迭代地圖 並刪除與 相關聯的沒有現有會話的請求？

對不起，如果這是一個很長的閱讀。即使你只能回答上述問題之一，它也會有所幫助！

Answer 1

1. 響應被保留，直到它可能超時。你一遍又一遍地推動新的信息。這就是彗星。您不會永遠循環獲取請求，您將處理從服務器流出的數據，因爲它會發出請求，1請求將持續到超時爲止，然後在完整的函數中發出另一個請求。

2. 同樣，響應仍然可用，您只能在上面寫，而不是每次關閉它。

3. 一種方法是對所有通知進行時間戳記並從某一時間加載數據，然後您的初始獲取請求會提供時間戳，然後您就可以獲得最新數據。

4. 我再次假設你持有它，直到它超時。

所以只是爲了更好地解釋這裏發生了什麼，

• 你的頁面加載和發送GET請求。
• 請求/響應存儲在地圖中。
• 然後每個更新都在SAME請求/響應對上發送。
• 您的獲取請求會偵聽readystate === 3（收到數據）並讀取獲取已發送的任何新數據的數據。
• 當他們超時/發送了一定數量的數據/無論他們被刪除。