Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Updated release notes

  • Loading branch information...
commit a765276e8c3f03135c9713a587922ddfaef069e9 1 parent bf5a081
@belaban authored
Showing with 91 additions and 315 deletions.
  1. +0 −315 doc/ReleaseNotes-3.1.0.txt
  2. +91 −0 doc/ReleaseNotes-3.2.0.txt
View
315 doc/ReleaseNotes-3.1.0.txt
@@ -1,315 +0,0 @@
-
-
-Release Notes JGroups 3.1.0
-===========================
-
-
-Author: Bela Ban
-
-*************************************************************************
-!! JGroups 3.1.0 is *not* API-backwards compatible with 2.x.x releases !!
-!! JGroups 3.1.0 is API-backwards compatible with 3.0.x releases !!
-*************************************************************************
-
-
-Below is a summary (with links to the detailed description) of the major new features, optimizations and bug fixes.
-
-
-
-
-New features
-============
-
-
-NAKACK2
--------
-[https://issues.jboss.org/browse/JGRP-1396]
-[https://issues.jboss.org/browse/JGRP-1402]
-
-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<Message>) is used to hold 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.
-
-
-UNICAST2: switch from NakReceiverWindow to Table
-------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1417]
-
-This is the same as JGRP-1396 above: NakReceiverWindow was replaced with Table<Message> and instead of a retransmitter
-per member, we now have *one* retransmitter task for *all* members.
-
-
-UNICAST: switch from AckSenderWindow / AckReceiverWindow to Table
------------------------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1419]
-
-Similarly to NAKACK2 and UNICAST2, both AckSenderWindow and AckReceiverWindow were replaced by Table, plus we only have
-*one* retransmission task for all members.
-The sender places messages into a Table<Message> and has a retransmission task for all members which periodically scans
-through all sender windows and resends *all* messages to their destinations. When an ACK is received for a given message,
-all messages below and including that message are removed.
-The receiver adds the messages to the table and then delivers as many messages as possible to the application. After
-that it sends an ACK for the highest message delivered.
-
-
-The changes in NAKACK2, UNICAST2 and UNICAST have several benefits:
-- Code simplification: having only one data structure (Table<Message>) 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<Message> 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 fewer 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: better merging in large clusters
-----------------------------------------
-[https://issues.jboss.org/browse/JGRP-1387]
-
-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 it
-also works with TCP.
-
-
-
-Synchronous messages
---------------------
-[https://issues.jboss.org/browse/JGRP-1389]
-
-Synchronous messages 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.
-
-For further details consult the manual (see below).
-
-
-New Total Order Anycast (TOA) protocol
---------------------------------------
-[https://issues.jboss.org/browse/JGRP-1442]
-
-Establishes total order between a subset of the cluster members, will be needed to totally order
-Infinispan DIST updates.
-
-
-
-Discovery protocol based on mod-cluster
----------------------------------------
-[https://issues.jboss.org/browse/JGRP-1322]
-
-If running AS7 and mod-cluster, the individual AS7 instances in a cluster can register directly with mod-cluster and
-read discovery information from mod-cluster. Thanks to Vladimir Blagojevic for designing and implementing this !
-
-
-New Rackspace based discovery protocol
---------------------------------------
-[https://issues.jboss.org/browse/JGRP-1226]
-
-Contributed by Gustavo Fernandes (thanks !). New discovery protocol using Rackspace's distributed store.
-
-
-New OpenStack based discovery protocol
---------------------------------------
-[https://issues.jboss.org/browse/JGRP-1478]
-
-Thanks to Thomas Segismont for contributing this new protocol !
-
-
-
-MPerf / UPerf: dynamic performance tests
-----------------------------------------
-[https://issues.jboss.org/browse/JGRP-1399]
-
-MPerf and UPerf are dynamic in the sense that they can be started on different nodes, and each instance will fetch the
-configuration (e.g. message size, number of senders, number of messages to send etc) from the coordinator. Any
-configuration change is broadcast to all members, so we don't need to restart them.
-MPerf is for multicast (= cluster wide messages) tests (successor to perf.Test) and UPerf tests unicasting.
-
-
-
-Probe: ability to set attributes
---------------------------------
-[https://issues.jboss.org/browse/JGRP-1390]
-
-E.g. probe.sh jmx=FLUSH.bypass=true
-
-
-
-Probe: encrypt diagnostics responses
-------------------------------------
-[https://issues.jboss.org/browse/JGRP-1470]
-
-The probe request and its responses are now encrypted.
-
-
-
-Restrict the interfaces that diagnostics listens on
----------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1403]
-
-Added diagnostics_bind_addresses="eth1,192.168.1.5,eth4"
-
-
-
-TestNG improvements
--------------------
-[https://issues.jboss.org/browse/JGRP-1423]
-
-Various improvements regarding TestNG.
-
-
-Reinstate return_entire_cache in discovery
-------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1430]
-
-Needed for MPING
-
-
-Added GMS.max_join_attempts to bound the number of times a join should be tried
--------------------------------------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1485]
-
-If max_join_attempts is exceeded, the joiner gives up and becomes a singleton.
-
-
-
-Optimizations
-=============
-
-
-Concurrent joining to a non-existing cluster
---------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1393]
-
-This reduces changes of merging as it takes more discovery responses into account.
-
-
-TP: reduce "no physical address for X; dropping message" warnings
------------------------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1422]
-
-This warning could be emitted when discovery didn't get all responses; the main reason was that discovery returned
-after num_initial_members responses were received, but if that value was less than the cluster size, we wouldn't get
-all responses and had to get the IP address (when not present) for P at the time of sending a message to P.
-
-
-Replaced MessageDispatcher.cast() with a non-blocking algorithm
----------------------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1414]
-
-This removes contention on a lock() acquired by cast() when multiple threads are invoking cast() concurrently.
-Note that this also affects RpcDispatcher.
-
-
-TCP: message senders are blocked by socket creation
----------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1462]
-
-Moved code that created new connections out of the path of normal message sending, to make the latter not get
-blocked by the former.
-
-
-
-
-Bug fixes
-=========
-
-DefaultSocketFactory: failed socket creations lead to socket leaks
-------------------------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1420]
-
-Especially important with TCPPING and static list of hosts that cannot be connected to.
-
-
-Global ThreadGroups not destroyed; leaks in web based applications
-------------------------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1410]
-
-The global (static) ThreadGroup was pulled into JChannel, making its lifetime congruent with the JChannel.
-
-
-Rsp incorrectly marked as received on suspecting a member
----------------------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1408]
-
-A member P's response (Rsp) is incorrectly set to 'received' if P is suspected (regression)
-
-
-ThreadGroup leak
-----------------
-[https://issues.jboss.org/browse/JGRP-1410]
-
-The global thread group could lead to leaks; moved to individual channels.
-
-
-SEQUENCER related bug fixes / improvements
-------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1449]
-[https://issues.jboss.org/browse/JGRP-1452]
-[https://issues.jboss.org/browse/JGRP-1458]
-[https://issues.jboss.org/browse/JGRP-1461]
-[https://issues.jboss.org/browse/JGRP-1468]
-[https://issues.jboss.org/browse/JGRP-1481]
-
-Various SEQUENCER related bug fixes and/or improvements, mainly dealing with edge cases (e.g. retransmission of
-messages on coordinator change in the correct order)
-
-
-Merge isn't triggered in some cases
------------------------------------
-[https://issues.jboss.org/browse/JGRP-1451]
-
-Modification of MERGE3 to handle this
-
-
-Message lost in NAKACK2 due to digest error
--------------------------------------------
-[https://issues.jboss.org/browse/JGRP-1455]
-
-
-TimeScheduler2 loses tasks
---------------------------
-[https://issues.jboss.org/browse/JGRP-1457]
-
-Edge case in which TimeScheduler can lose tasks
-
-
-
-
-Manual
-======
-
-The 3.x manual is at http://www.jgroups.org/manual-3.x/html/index.html.
-The 2.x manual is at http://www.jgroups.org/manual/html/index.html.
-
-
-
-The complete list of features and bug fixes can be found at http://jira.jboss.com/jira/browse/JGRP.
-
-
-Bela Ban, Kreuzlingen, Switzerland
-Vladimir Blagojevic, Toronto, Canada
-Richard Achmatowicz, Toronto, Canada
-Sanne Grinovero, Newcastle, Great Britain
-
-July 2012
-
View
91 doc/ReleaseNotes-3.2.0.txt
@@ -0,0 +1,91 @@
+
+
+Release Notes JGroups 3.2.0
+===========================
+
+
+Author: Bela Ban
+
+********************************************************************************
+!! JGroups 3.2.0 is *not* API-backwards compatible with 2.x.x releases !!
+!! JGroups 3.2.0 is API-backwards compatible with previous 3.x releases !!
+********************************************************************************
+
+
+Below is a summary (with links to the detailed description) of the major new features, optimizations and bug fixes.
+
+
+
+
+New features
+============
+
+
+RELAY2: multi-site clustering
+-----------------------------
+[https://issues.jboss.org/browse/JGRP-1433]
+
+Provides clustering between multiple sites; successor to RELAY (which allowed for only 2 sites). RELAY2 is added to the
+top of the stack and relays both multicast and unicast messages between sites (local clusters).
+For documentation go to http://www.jgroups.org/manual-3.x/html/user-advanced.html#Relay2Advanced.
+
+
+
+
+Optimizations
+=============
+
+
+
+
+
+
+Bug fixes
+=========
+
+GroupRequest: received and suspected is counted twice
+-----------------------------------------------------
+[https://issues.jboss.org/browse/JGRP-1505]
+
+This could lead to premature termination of blocking RPCs.
+
+
+
+NAKACK / NAKACK2: modification of headers leads to unneeded retransmissions
+---------------------------------------------------------------------------
+[https://issues.jboss.org/browse/JGRP-1502]
+
+When copying messages on a retransmission, the headers are not copied. When NAKACK{2} therefore modifies a header
+in place, we're changing the type of the message (normal message --> retransmit message). This is not incorrect, but
+leads to unneeded retransmissions.
+
+
+RSVP: incorrect updating of membership response list
+----------------------------------------------------
+[https://issues.jboss.org/browse/JGRP-1503]
+
+This could lead to TimeoutExceptions when a new view was received before the call terminated.
+
+
+
+
+
+
+
+Manual
+======
+
+The manual is at http://www.jgroups.org/manual-3.x/html/index.html.
+
+
+
+The complete list of features and bug fixes can be found at http://jira.jboss.com/jira/browse/JGRP.
+
+
+Bela Ban, Kreuzlingen, Switzerland
+Vladimir Blagojevic, Toronto, Canada
+Richard Achmatowicz, Toronto, Canada
+Sanne Grinovero, Newcastle, Great Britain
+
+Aug 2012
+
Please sign in to comment.
Something went wrong with that request. Please try again.