Java多播通訊框架 JGroups 3.1.0.Alpha2 發布

JGroups是一個可靠的群組通訊Java工具包。它基于IP組播(IP multicast)，但在可靠性，組成員管理上對它作了擴展。

1，對所有接收者的消息的無丟失傳輸（通過丟失消息的重發）
2，大消息的分割傳輸和重組
3，消息的順序發送和接收
4，原子性：消息要么被所有接收者接收，要么全不

1，可以知道組內有哪些成員
2，成員的加入，離開，掉線等的通知

- 組的創建與刪除。組成員能在LAN或WAN環境內互相發送消息
- 組的成員加入或離開
- 組成員的檢測和通知：加入，離開，掉線
- 檢測與移除已掉線的成員
- 消息的組播 (member-to-group或point-to-multipoint)
- 消息的點對點發送 (member-to-member或point-to-point)
- 支持UDP (IP Multicast), TCP, JMS等傳輸協議
- 免費開放源代碼（LGPL）

JGroups 3.1.0.Alpha2 發布了，盡管是 alpha2 版，但該版本還是相當穩定，而且將會在很短時間內發布穩定版。

目前還遺留幾個小問題。

JGroups 3.1 主要新特性有：

• A new protocol NAKACK2 : this is a successor to NAKACK (which will get phased out over the next couple of releases). The 2 biggest changes are:
  • A new memory efficient data structure (Table ) is used to store messages to be retransmitted. It can grow and shrink dynamically, and replaces NakReceiverWindow.
  • There is no Retransmitter associated with each table, and we don't create an entry *per* missing sequence number (seqno) or seqno range. Instead, we have *one* single retransmission task, which periodically (xmit_interval ms) scans through *all* tables, identifies gaps and triggers retransmission for missing messages. This is a significant code simplification and brings memory consumption down when we have missing messages.
• Changes to UNICAST2 and UNICAST : in both cases, we switch from NakReceiverWindow  / AckSenderWindow / AckReceiverWindow to Table and instead of a retransmitter per member, we now have *one* retransmitter task for *all* members.
• The changes in NAKACK2, UNICAST2 and UNICAST have several benefits:
  • Code simplification : having only one data structure (Table ) instead of several ones (NakReceiverWindow, AckSenderWindow, AckReceiverWindow), plus removing all Retransmitter implementations leads to simpler code.
  • Code reduction : several classes can be removed, making the code base simpler to understand, and reducing complexity
  • Better maintainability : Table is now an important core data structure, and improvements to it will affect many parts of JGroups
  • Smaller memory footprint : especially for larger clusters, having less per-member data (e.g. retransmission tasks) should lead to better scalability in large clusters (e.g. 1000 nodes).
  • Smooth transition : we'll leave NAKACK (and therefore NakReceiverWindow and Retransmitter) in JGroups for some releases. NAKACK / NakReceiverWindow have served JGroups well for over a decade, and are battle-tested. When there is an issue with NAKACK2 / Table in  production, we can always fall back to NAKACK. I intend to phase out NAKACK after some releases and a good amount of time spent in production around the world, to be sure NAKACK2 works well
• MERGE3 : merging is frequent in large clusters. MERGE3 handles merging in large clusters better by
  • preventing (or reducing the chances of) concurrent merges
  • reducing traffic caused by merging
  • disseminating {UUID/physical address/logical name} information, so every node has this information, reducing the number of times we need to ask for it explicitly.
  • MERGE3 was written with UDP as transport in mind (which is the transport recommended for large clusters anyway), but italso works with TCP. 
• Synchronous messages : they  block the sender until the receiver or receivers have ack'ed its delivery. This allows for 'partial flushing' in the sense that all messages sent by a member P prior to M will get delivered at all receivers before delivering M.
  This is related to FLUSH, but less costly and can be done per message. For example, if a unit of work is done, a sender could send an RSVP tagged message M and would be sure that - after the send() returns - all receivers have delivered M.
  To send an RSVP marked messages, Message.setFlag(Message.Flag.RSVP) has to be used.
  A new protocol (RSVP) needs to be added to the stack. See the documentation (link below) for details.
• A new rackspace-based discovery protocol
• Concurrent joining to a non-existing cluster is faster
• Elimination (or reduction of) "no physical address for X; dropping message" warnings
• Elimination of global JGroups ThreadGroup leaks
• Elimination of socket leaks with TCPPING