HTTPS clone URL
Subversion checkout URL
The JGroups project
3.3 3.4 3.5 BRANCH_JGROUPS_2_2_8_JDK_1_3_CDC BRANCH_JGROUPS_2_2_9_1_CDC Branch_2_8_temp Branch_JG_2_2_1 Branch_JG_2_2_7_SOLOMIO_3231 Branch_JGroups_2_2_7 Branch_JGroups_2_2_9_1 Branch_JGroups_2_3 Branch_JGroups_2_4 Branch_JGroups_2_5 Branch_JGroups_2_6 Branch_JGroups_2_7 Branch_JGroups_2_8 Branch_JGroups_2_8_LogicalAddresses Branch_JGroups_2_9 Branch_JGroups_2_10 Branch_JGroups_2_11 Branch_JGroups_2_12 Branch_JGroups_3_0 Branch_JGroups_3_2 JGROUPS_2_2_8 JGRP-1396 JGRP-1396-2 JGRP-1401 JGRP-1407 JGRP-1411 JGRP-1412 JGRP-1413 JGRP-1416 JGRP-1417 JGRP-1428 JGRP-1433 JGRP-1441 JGRP-1443 JGRP-1444 JGRP-1449.reopen JGRP-1451 JGRP-1455 JGRP-1461 JGRP-1466 JGRP-1468 JGRP-1475 JGRP-1484 JGRP-1502 JGRP-1508 JGRP-1528 JGRP-1539 JGRP-1542 JGRP-1547 JGRP-1551 JGRP-1555 JGRP-1557 JGRP-1564 JGRP-1581 JGRP-1587 JGRP-1588 JGRP-1599 JGRP-1603 JGRP-1632 JGRP-1649 JGRP-1660 JGRP-1662 JGRP-1675 JGRP-1687 JGRP-1710 JGRP-1716 JGRP-1742 JGRP-1789 JGRP-1821 JGRP-1877 JGroups_2_4_5_GA_JGRP_549 JGroups_2_4_5_GA_JGRP-983 JGroups_2_4_5_GA_JGRP-1000 JGroups_2_4_5_GA_JGRP-1060 JGroups_2_4_7_GA_JGRP-1207 JGroups_2_4_7_GA_JGRP-1279 JGroups_2_4_7_GA_JGRP-1279_JGRP-1311 JGroups_2_4_10_Final_JGRP-1382 JGroups_2_6_13_GA_JGRP-1205_JGRP-1282 JGroups_2_6_13_GA_JGRP-1228 JGroups_2_6_16_JGRP-1205 JGroups_2_6_16_JGRP-1205_JGRP-1254 JGroups_2_6_16_JGRP-1383 JGroups_2_6_19_GA_JGRP-1383 JGroups_2_6_20_JGRP-1383 JGroups_2_6_20_JGRP-1383_JGRP-1497 bunder_perf_cclq bundler_perf cache-details daisy hpdrago-prio ids master master_with_javadoc mfc2 newdoc origin revert-156-fd-host-falsesuspect t_jgrp_1007 testng treemesh uuperf
Nothing to show
Nothing to show
JGRP-1967 SASL: correctly handle merge requests
JGroups - A Framework for Group Communication in Java ======================================================== March 3, 1998 Bela Ban 4114 Upson Hall Cornell University Ithaca, NY 14853 email@example.com firstname.lastname@example.org JGroups is a Java library for reliable group communication. It consists of 3 parts: (1) a socket-like API for application development, (2) a protocol stack, which implements reliable communication, and (3) a set of building blocks, which give the developer high-level abstractions (e.g. ReplicatedHashMap, an implementation of java.util.Map). The API (a channel) looks like a socket: there are methods for joining and leaving groups, sending and receiving messages, getting the shared group state, and registering for notifications when a member joins, or an existing member leaves or crashes. The protocol stack is a list of protocols, through which each message passes. Each protocol implements an up() and down() method, and may modify, reorder, encrypt, fragment/unfragment, drop, or pass a message up/down. The protocol stack is created according to a specification given when a channel is created. New protocols can be plugged into the stack easily. Building blocks hide the channel and provide a higher abstraction. Example: ReplicatedHashMap implements java.util.Map and implements all methods that change the map (clear(), put(), remove()). Those methods are invoked on all hashmap instances in the same group simultaneously, so that all hashmaps have the same state. A new hashmap uses a state transfer protocol to initially obtain the shared group state from an existing member. This allows for replication of data structures across processes. Group communication is important in the following situations: - A service has to be replicated for availability. As long as at least one of the servers remains operational, the service itself remains operational - Service requests have to be balanced between a set of servers - A large number of objects have to be managed as one entity (e.g. a management domain) - Notification service / push technology: receivers subscribe to a channel, senders send data to the channels, channels distribute data to all receivers subscribed to the channel. Used for example for video distribution, videoconferencing JGroups deliberately models a rather low-level message-oriented middleware (MOM) model. The reason is that we don't want to impose a one-size-fits-all model on the programmer, who usually will want to extend the model in various (previously unconceived) ways anyway. Providing low level Java classes allows the programmer to extend/replace classes at will, as the granularity of the system is finer.