Release Notes JGroups 2.3 ========================= Version: $Id: ReleaseNotes-2.3.txt,v 1.4 2006/04/26 07:56:01 belaban Exp $ Author: Bela Ban Multiplexer ----------- In JBoss we have multiple JGroups channels, one for each application (e.g. JBossCache, ClusterPartition etc). The goal of the Multiplexer is to combine all stacks with the *same* configuration into one, and have multiple apps on top of that same channel. To do this we have to introduce multiplexing and demultiplexing functionality, ie. each app will have to have a unique application ID (a string), and when sending a message, the message has to be tagged with that ID. When receiving a message, it will be dispatched to the right app based on the ID attached to the message. We require special handling for VIEW and SUSPECT messages: those need to be dispatched to *all* apps. State transfer also needs to be handled specially, here we probably have to use thread locals, or change the API (TBD). When deployed into JBoss, the Multiplexer will be exposed as an MBean, and all apps that depend on it will be deployed with dependency injection on the Multiplexer. Of course, the old configuration will still be supported. The config of the Multiplexer is done via a config file, which lists a number of stacks, each keyed by a name, e.g. "udp", "tcp", "tcp-nio" etc. See ./conf/stacks.xml for an example. An app is configured with the name of a stack, e.g. "udp", and a reference to the Multiplexer MBean. It will get a proxy channel through which all of its communication will take place. The proxy channel (MuxChannel) will mux/demux messages to the real JGroups channel. The advantage of the Multiplexer is that we can reduce N channels into M where M < N. This means fewer threads, therefore fewer context switches, less memory consumption and easier configuration and better support. Partial state transfer ---------------------- The Channel.getState() method can now define the ID of a substate to be fetched. This allows applications to get only a part of its state, not the entire state. See http://www.jgroups.org/javagroupsnew/docs/manual/html/user-channel.html#PartialStateTransfer for details. AUTH ---- AUTH is a protocol directly under GMS, which allows to authenticate members who want to join a group. Based on a pluggable authentication mechanism, new members are either admitted or rejected. In the latter case, Channel.connect() will fail with a security exception. For details see JGroups/doc/design/AUTH.txt. Sequencer based total order protocol ------------------------------------ SEQUENCER is an improved implementation of total order, and faster than TOTAL. When sending a message to the group, the sender sends the message via unicast to the coordinator, who then broadcasts the message (on behalf of the sender) to all members, with a unique sequence number. The coordinator uses FIFO, but since there is only 1 sender, this results in total order. SEQUENCER can be used for example to maintain identical replicas of a (JMS) queue: senders and receivers can send and receive messages to/from any queue replica simultaneously, without affecting the consistency of all replicas across the cluster. A quick 2 node performance test (perf.Test) with 2 million 1K messages showed ca 6500 messages/sec with sequencer.xml, compared to ca. 10500 messages/sec with fc-fast-minimalthreads.xml. For details see JGroups/doc/design/SEQUENCER.txt. ENCRYPT enhancements -------------------- The encrypt_entire_message flag (if set to true) will now encrypt the entire message (including the headers), as opposed to only encrypting the message buffer. Note that this operation requires serialization of the message, so setting this option to true is expensive. Why use it ? When one wants to prevent eavesdroppers from snooping out information located in the (non-encrypted) headers, such as sequence numbers. Incompatibilities to previous version ------------------------------------- Changed method signature of the RpcDispatcher.callRemoteMethod() methods to throw a Throwable. Previously they returned the exception as an object, now the exception will be thrown. Callers of these methods have to change their code, so this is an incompatible change. However, these calls are not used in JBossCache and JBoss Clustering. (http://jira.jboss.com/jira/browse/JGRP-154) Enhancements and bug fixes -------------------------- - FD_SOCK now uses the bind address of the transport unless a bind_addr is specifically specified, or the -Dbind.address system property is used. - FRAG had a bug that corrupted messages when messages were sent concurrently in multiple threads Documentation ------------- - The user's guide has been updated (http://www.jgroups.org/javagroupsnew/docs/manual/html/index.html) -------------------------------------------------------------------------------- Changes: Release Notes - JGroups - Version 2.3 ** Feature Request * [JGRP-37] - TCP should generate a SUSPECT event when connection is closed * [JGRP-47] - Support for IPv6 * [JGRP-91] - Specification of on-the-wire protocol * [JGRP-107] - Multiple building blocks on the same channel * [JGRP-112] - JGroups ChannelFactory MBean * [JGRP-118] - Partial state transfer * [JGRP-119] - Multiplexing multiple building blocks over the same JChannel/PullPushAdapter * [JGRP-132] - Support for 64 bit Operating Systems * [JGRP-133] - Multicast IM-ALIVE message to all members when suspected * [JGRP-164] - AUTH protocol * [JGRP-172] - Sequencer based total order protocol * [JGRP-183] - Create global thread group for all JGroups threads * [JGRP-185] - TCP/TCP_NIO: close connection to member X when X leaves group * [JGRP-190] - ENCRYPT: encrypt headers too, not just message body * [JGRP-197] - Create more light-weight distribution * [JGRP-200] - Include the cluster name in the thread name(s) and/or global ThreadGroup * [JGRP-222] - AUTH: authenticate members based on fixed lists * [JGRP-228] - Make RspList implement Map ** Bug * [JGRP-137] - Broadcast message fail while executing state transfer * [JGRP-148] - Handling of state transfer when coordinator crashes * [JGRP-154] - Exceptions thrown my the remote method are not handled correctly * [JGRP-160] - MessageDispatcher on top of PullPushAdapter does not remove MemberShipListener * [JGRP-169] - getState() on a channel causes castMessage() to timeout * [JGRP-173] - FD_SOCK picks random bind address if neither bind.address nor srv_sock_bind_addr are set * [JGRP-175] - ReplicatedHashtable that does not call stateTransferCompleted * [JGRP-177] - Join problem * [JGRP-184] - OutOfMemoryError after FD problems * [JGRP-186] - Channel.getState() with timeout of 0 causes immediate resuming of stability processing * [JGRP-192] - RpcDispatcher eats exceptions caused by serialization * [JGRP-194] - Problems with concurrent processing in MessageDispatcher * [JGRP-195] - Use KEEP_ALIVE for sockets in FD_SOCK and TCP ConnectionTable * [JGRP-198] - Incorrect delivery order for unicast and multicast messages if use_incoming_packet_handler is set to false * [JGRP-202] - NotSerializableException occurs when using UDP_NIO * [JGRP-209] - Thread leakage in ConnectionTable with TCP as transport * [JGRP-211] - MessageDispatcher/RequestCorrelator/GroupRequest eat exceptions * [JGRP-215] - FRAG corrupts messages under load * [JGRP-216] - FRAG2 corrupts messages * [JGRP-218] - Memgers linger around after connection is closed * [JGRP-224] - Issue with QuoteServer / QuoteClient * [JGRP-225] - LargeState test doesn't work with fc-fast-minimalthreads.xml and state of 5MB * [JGRP-233] - STABLE should ignore unicast messages for triggering of stable message * [JGRP-234] - TCP-NIO doesn't deliver messages (handshaking problem) * [JGRP-235] - Messages sent directly after joining occasionally lost on high load * [JGRP-238] - Unicasts to non-coordinators are discarded after merge * [JGRP-241] - Use the correct MBeanServer if multiple MBeanServers are present * [JGRP-245] - Timer leak in GossipClient ** Task * [JGRP-73] - Convert ProgGuide to docbook * [JGRP-157] - Test multiple partitions and subsequent merges * [JGRP-174] - Protocol.init() should be called after all protocols have been created and linked to each other * [JGRP-178] - Investigate NAKACK problem * [JGRP-179] - Behavior of NAKACK and UNICAST in the presence of exceptions (e.g. OOM) * [JGRP-191] - Need license notices * [JGRP-207] - add "type" key attribute to ObjectNames of JGroups MBeans * [JGRP-208] - Look into Util.objectTo/FromByteBuffer() * [JGRP-214] - Look into using the backport of concurrent.jar * [JGRP-219] - Look into removing block_sending from JChannel * [JGRP-220] - Remove suspended / suspend() / resume() from JChannel * [JGRP-221] - Update documentation for Receiver, Multiplexer * [JGRP-229] - IpAddress(host, port) falls back to localhost if host cannot be resolved ** Release * [JGRP-199] - Release 2.3 final