Java多播通讯框架 JGroups 3.1.0.Alpha2 发布

     <div id="p_fullcontent" class="detail">     <p><a href="http://www.open-open.com/lib/view/open1325078709139.html" target="_blank">JGroups</a>是一个可靠的群组通讯Java工具包。它基于IP组播(IP multicast)，但在可靠性，组成员管理上对它作了扩展。</p>     <div id="tf_edit_html_title" class="tf_edit_html_title">      JGroups的可靠性体现在：     </div>     <p>1，对所有接收者的消息的无丢失传输（通过丢失消息的重发）<br /> 2，大消息的分割传输和重组<br /> 3，消息的顺序发送和接收<br /> 4，原子性：消息要么被所有接收者接收，要么全不</p>     <div id="tf_edit_html_title" class="tf_edit_html_title">      JavaGroups的成员关系管理体现在：     </div>     <p>1，可以知道组内有哪些成员<br /> 2，成员的加入，离开，掉线等的通知</p>     <div id="tf_edit_html_title" class="tf_edit_html_title">      JavaGroups的主要功能特征：     </div>     <p>- 组的创建与删除。组成员能在LAN或WAN环境内互相发送消息<br /> - 组的成员加入或离开<br /> - 组成员的检测和通知：加入，离开，掉线<br /> - 检测与移除已掉线的成员<br /> - 消息的组播 (member-to-group或point-to-multipoint)<br /> - 消息的点对点发送 (member-to-member或point-to-point)<br /> - 支持UDP (IP Multicast), TCP, JMS等传输协议<br /> - 免费开放源代码（LGPL）</p>     <p><img style="width:563px;height:422px;" alt="Java多播通讯框架 JGroups 3.1.0.Alpha2 发布" src="https://simg.open-open.com/show/d94a1ef31e58a6b6f3ce94c47d03637b.jpg" /><br /> </p>     <p>JGroups 3.1.0.Alpha2 发布了，尽管是 alpha2 版，但该版本还是相当稳定，而且将会在很短时间内发布稳定版。</p>     <p>目前还遗留<a href="/misc/goto?guid=4958328878414713555" target="_blank">几个小问题</a>。</p>     <p>JGroups 3.1 主要新特性有：</p>     <ul>      <li><strong>A new protocol NAKACK2</strong> : this is a successor to NAKACK (which will get phased out over the next couple of releases). The 2 biggest changes are:       <ul>        <li>A new memory efficient data structure (Table ) is used to store messages to be retransmitted. It can grow and shrink dynamically, and replaces NakReceiverWindow. </li>        <li>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.</li>       </ul> </li>      <li><strong>Changes to UNICAST2 and UNICAST</strong> : 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. </li>      <li>The changes in NAKACK2, UNICAST2 and UNICAST have several benefits:       <ul>        <li><strong>Code simplification</strong> : having only one data structure (Table ) instead of several ones (NakReceiverWindow, AckSenderWindow, AckReceiverWindow), plus removing all Retransmitter implementations leads to simpler code. </li>        <li><strong>Code reduction</strong> : several classes can be removed, making the code base simpler to understand, and reducing complexity</li>        <li><strong>Better maintainability</strong> : Table is now an important core data structure, and improvements to it will affect many parts of JGroups </li>        <li><strong>Smaller memory footprint</strong> : 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).</li>        <li><strong>Smooth transition</strong> : 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</li>       </ul> </li>      <li><strong>MERGE3</strong> : merging is frequent in large clusters. MERGE3 handles merging in large clusters better by       <ul>        <li>preventing (or reducing the chances of) concurrent merges</li>        <li>reducing traffic caused by merging</li>        <li>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.</li>        <li>MERGE3 was written with UDP as transport in mind (which is the transport recommended for large clusters anyway), but italso works with TCP.  </li>       </ul> </li>      <li><strong>Synchronous messages</strong> : 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.<br /> 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.<br /> To send an RSVP marked messages, Message.setFlag(Message.Flag.RSVP) has to be used.<br /> A new protocol (RSVP) needs to be added to the stack. See the documentation (link below) for details.</li>      <li><strong>A new rackspace-based discovery protocol</strong> </li>      <li><strong>Concurrent joining to a non-existing cluster is faster</strong> </li>      <li><strong>Elimination (or reduction of) "no physical address for X; dropping message" warnings</strong> </li>      <li><strong>Elimination of global JGroups ThreadGroup leaks</strong> </li>      <li><strong>Elimination of socket leaks with TCPPING</strong> </li>     </ul> 相关链接：     <br /> [1]     <a href="/misc/goto?guid=4958328879233180439">https://github.com/belaban/JGroups/blob/master/doc/ReleaseNotes-3.1.0.txt</a>     <br /> [2]     <a href="/misc/goto?guid=4958328880041287092">http://www.jgroups.org/manual-3.x/html/index.html</a>     <br /> [3]     <a href="/misc/goto?guid=4958328880846345670">https://sourceforge.net/projects/javagroups/files/JGroups/3.1.0.Alpha2/</a>     <p></p>    </div>