差異處
這裏顯示兩個版本的差異處。
Both sides previous revision 前次修改 下次修改 | 前次修改 | ||
java:web:wicket:websocket_disconn_handling [2018/11/02 22:22] tony [Handle On Server Side] |
java:web:wicket:websocket_disconn_handling [2023/06/25 09:48] (目前版本) |
||
---|---|---|---|
行 2: | 行 2: | ||
====== Wicket - Websocket disconnection handling ====== | ====== Wicket - Websocket disconnection handling ====== | ||
===== Problem ===== | ===== Problem ===== | ||
- | 造成websocket突然斷線的原因很多,像是網路不穩定或是閒置過久遭server或是browser中斷連線等,都有可能導致接下來的工作不正常。因此我們需要方法去處理連線中斷的情況。 | + | 造成Websocket突然斷線的原因很多,像是網路不穩定或是閒置過久遭server或是browser中斷連線等,都有可能導致接下來的工作不正常。因此我們需要方法去處理Websocket連線中斷的情況。本篇文章分享我們有使用過的解決方式,供大家參考。 |
===== How to? ===== | ===== How to? ===== | ||
- | 我們Web框架使用Apache Wicket(6.22),而Server是Jetty(9.3.9)。 | + | 我們Web框架使用Apache Wicket(6.22),而Server是Jetty(9.3.9)。我們最早使用的解法是在server side判斷連線狀態,但這並非百分之百的解決方式,所以最近改使用client side的解法。除此之外,ping&pong也是一種解決方法,但由於Wicket本身不支援,且套用send message去實作較複雜,因此不在本篇文章討論範圍內。 |
==== Handle On Server Side ==== | ==== Handle On Server Side ==== | ||
- | 我們最早版本是在Server Side根據user request做處理,假如user request對應的websocket連線已中斷,那我們就會透過AjaxRequestTarget送一個reload給client: | + | 我們在Server Side根據user request做處理,假如user request對應的Websocket連線已中斷,那我們就會透過AjaxRequestTarget送一個reload給client: |
<code java> | <code java> | ||
public class WebSocketCheckListener extends AbstractRequestCycleListener { | public class WebSocketCheckListener extends AbstractRequestCycleListener { | ||
行 32: | 行 32: | ||
} | } | ||
</code> | </code> | ||
- | 這做法不是不好,只是有點繞。假如連線問題是client可以得知的,是不是交由client去處理就好了呢? | + | 這做法很簡單,但server無法百分之百的偵測到連線中斷。我們就曾經在會議中,於切換完ip的電腦繼續使用我們的web;但由於Websocket斷線而造成後來的畫面無法正常顯示。因此我們開始考慮client side的作法。 |
==== Handle On Client Side ==== | ==== Handle On Client Side ==== | ||
+ | Wicket Websocket client的api可以參考[[https://cwiki.apache.org/confluence/display/WICKET/Wicket+Native+WebSockets|link]]。在callback的event中,我們會希望發生網路問題或者是Websocket中斷時,closed與error的event會被呼叫,而我們也只需要處理這兩種訊息;然而經過我實際在chrome、firefox、ie11上,分別對client、server做網路連線中斷相關測試後,發現事與願違。\\ | ||
+ | \\ | ||
+ | 舉例來說,在我將server網路線拔除再插回去時,不會有任何事件發生,直到client發送訊息給server後,才會發生closed event。面對這樣問題,我就需要透過send message來偵測Websocket是否斷線。 | ||
+ | \\ | ||
+ | 首先讓我們處理最簡單的部分,error event。目前只會發生在網路有問題的情況,因此處理很簡單,就是重新連線。在這裡我使用了一個名為isWSConnected的變數,是用來區別websocketed是否已處於連線的狀態: (假如我可以改Wicket的js,我不會想這麼做) | ||
+ | <code javascript> | ||
+ | Wicket.Event.subscribe("/websocket/error", function(jqEvent) { | ||
+ | isWSConnected = false; | ||
+ | Wicket.WebSocket.close(); | ||
+ | Wicket.WebSocket.createDefaultConnection(); | ||
+ | }); | ||
+ | </code> | ||
+ | 在成功建立連線後,我們server會給client發送訊息,因此針對message event我們會將isWSConnected設為true;假如你把isWSConnected設定放在open event中,有可能Websocket會是處於連線中的狀態: | ||
+ | <code javascript> | ||
+ | Wicket.Event.subscribe("/websocket/message", function(jqEvent, message) { | ||
+ | isWSConnected = true; | ||
+ | // handle message | ||
+ | }); | ||
+ | </code> | ||
+ | closed event的部分我最後再說明,請讓我先說明連線偵測的部分。由於我們的操作都是屬於ajax的request,且偵測做在client有請求時才發送會比定時發送有效率;因此我們將這個檢查放在ajax請求前的事件中,主要做以下幾件事情: | ||
+ | - 連線關閉時,重新建立連線;此時Wicket.WebSocket.INSTANCE未被初始化。 | ||
+ | - 假如Wicket.WebSocket.INSTANCE有被初始化,但isWSConnected為false,代表正在建立連線中。我們會略過偵測動作。 | ||
+ | - 最後是透過Wicket.WebSocket.send發送訊息給server,以確認網路狀態。詳細內容後面說明。 | ||
+ | <code javascript> | ||
+ | Wicket.Event.subscribe('/ajax/call/beforeSend', function(jqEvent, attributes, jqXHR, errorThrown, textStatus) { | ||
+ | if( !Wicket.WebSocket.INSTANCE ){ | ||
+ | Wicket.WebSocket.createDefaultConnection(); | ||
+ | } else { | ||
+ | if( !isWSConnected ) { | ||
+ | console.log('websocket is connecting..'); | ||
+ | return; | ||
+ | } | ||
+ | |||
+ | try { | ||
+ | Wicket.WebSocket.send('ping'); | ||
+ | _lastSendPing = new Date(); | ||
+ | } catch(e) { | ||
+ | console.log(e.messsage); | ||
+ | Wicket.WebSocket.close(); | ||
+ | Wicket.WebSocket.createDefaultConnection(); | ||
+ | } | ||
+ | } | ||
+ | }); | ||
+ | </code> | ||
+ | Wicket.WebSocket.send後,有可能會發生closed,也有可能會發生error,也有可能會拋例外;這時大家可能會問: 為何你closed event不直接像其它案例一樣,重新建立連線就好? 這是由於我們希望使用者在一段時間沒任何操作後,會自動登出系統;然而重新建立連線的動作,是會延展session時間而導致不會timeout,因此我們僅在使用者有操作後的closed event才會重新建立連線。最後就是對closed event的處理: | ||
+ | <code javascript> | ||
+ | Wicket.Event.subscribe("/websocket/closed", function(jqEvent) { | ||
+ | isWSConnected = false; | ||
+ | Wicket.WebSocket.close(); | ||
+ | if( !_lastSendPing ) { | ||
+ | return; | ||
+ | } | ||
+ | |||
+ | var isPingExpired = (new Date()- _lastSendPing) >= 10*1000; | ||
+ | _lastSendPing = null; | ||
+ | if( isPingExpired ){ | ||
+ | return; | ||
+ | } | ||
+ | |||
+ | Wicket.WebSocket.createDefaultConnection(); | ||
+ | }); | ||
+ | </code> | ||
+ | 這裡搭配偵測斷線的動作,假如在send message後的10秒內發生closed,就會重新連線。這裡使用Date而不用Boolean是考慮到send message正常,但因其它原因closed時,flag為true而做了非預期的重新連線。假如send message能夠做成callback method,會比較理想,否則使用我目前的方法實做會較容易。 | ||
+ | \\ | ||
+ | \\ | ||
+ | 希望以上內容對大家有幫助。 | ||
+ | ===== Reference ===== | ||
+ | * [[https://cwiki.apache.org/confluence/display/WICKET/Wicket+Native+WebSockets|Wicket Native WebSockets]] | ||
+ | |||
+ | ====== ====== | ||
+ | ---- | ||
+ | \\ | ||
+ | ~~DISQUS~~ |