2013-10-11 16 views
0

我使用netty 4並利用ChannelPipeline將協議狀態管理等內容與編解碼器分開(例如)。這真的很好 - 我喜歡單線程(當你想要它)管道的性質。重新連接,同時與netty保持狀態4

我也想管理斷開/重新連接。

但是 - 當'斷開' - 我想堅持消息,否則會被髮送給誰斷開的兄弟。 我想這樣做,同時仍然使用netty功能(即仍然使用我的處理程序在管道中進行編碼等持續存在之前)。顯然,這個(邏輯)管道已經超過了一個通道的生命週期(當發生重新連接時,我將使用登錄消息中發送的會話名稱並將所有狀態重新導回到新通道的管道中) 。

很明顯,我可以在netty之外完成所有的工作 - 但我仍然希望繼續使用管道進行編碼等,而斷開連接。 我現在所能想到的就是使用某種'/ dev/null /'風格(自定義)通道,當我們斷開連接時,它將丟棄所有內容,並在斷開連接時正確重新建立流水線在這個'假'死信息通道)並重新連接,並自定義EventExecutorGroup保持線程的好(即固定在'邏輯會話'狀態 - 所以移動通道到信道)。這似乎有點'唉':)

是否有任何現有'模式'我沒有看到文件處理斷開&重新連接,同時保持狀態和使用管道功能在netty 4之間的時期?

回答

0

聽起來好像您正在努力確保向客戶提供「盡力而爲」服務。我處理類似的事情。

上游想要一個連接有隊列和通道組的接收器。當客戶端連接其中一個接收器時,它們將被創建並添加到通道組中。添加消息時,它們將被添加到隊列中並寫入通道組。組中的每個連接都會收到這些消息。

重新連接時,您(神奇地)將新客戶端映射回接收器,並(奇蹟般地)確定其在隊列中的位置,並從隊列中發送增量,並將其添加到組中。 「神奇」的部分取決於你。

您確實需要擔心此代碼的併發性,並且您不得不擔心手動收集接收器。

我是番石榴的TTL和LRU緩存的忠實粉絲,我已經在這方面使用它們。

更新時間:

基於下面的澄清,你問動態構建您的管道和再利用處理。管道處理程序可以重複使用,所以這個sequence diagram應該基本上做你想要的。

該圖中未包含的內容是寫入處理程序的外部進程。當ctx被分離並且連接關閉時,您需要在有狀態處理程序中處理緩衝給客戶端。我認爲你可以嘗試的確切機制。

希望這會有所幫助。

+0

謝謝 - ChannelGroups絕對看起來很有趣。不_quite_確定他們是我後來的(我可能誤解了!)。看,我想要一個單一的管道進行各種轉換/編碼。在管道中的某個點,我堅持下去。現在,如果連接斷開,我想繼續轉換/編碼/持續 - 但顯然不會嘗試發送到死信道。不是單個消息 - >多通道(這不會重複編碼等)。所以仍然不能看到一個乾淨的方式,而不是通過'channelUnregistered'通知創建新的虛擬頻道:( – Aconstnull

+0

我想我所得到的是整個管道的工作方式似乎相當豐富和有用:而且我希望它不會如果你想切換底層的「頻道」 - 或者根本沒有(主動)頻道 - 同時保持良好的線程模型等,那麼所有的東西都會崩潰。否則,可能發生的事情是越來越多的東西向上移動,在堆棧中的一個層,netty只是用來發送預編碼(並在這種情況下,持續,)字節愛好者...... – Aconstnull

+0

更新了答案以迴應你的澄清。 –