One pager on RMI-IIOP FOLB

1. Introduction

1.1. Project/Component Working Name:

RMI-IIOP Load Balancing and Failover

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Sheetal Vartak : sheetal.vartak@sun.com

1.3. Date of This Document:

08/04/06

2. Project Summary

2.1. Project Description:

With RMI-IIOP load balancing, IIOP client requests are distributed to different server instances or name servers. The goal is to spread the load evenly across the cluster, thus providing scalability. When one of the server instances is down, the load (request) is sent to the next available server instance. This is Failover of RMI-IIOP requests. In 9.1, there is support for dynamically reconfigured clusters. In essence, the client is not required to know all the endpoints (server instances) taking part in FOLB. The server instances in the participating cluster are made aware of its peer dynamically via GMS (Group Membership Service). Weighted Round Robin algorithm implemented apart from existing implementation.

2.2. Risks and Assumptions:

No Risks involved. The basic FOLB functionality has been successfully tested in 8.1 EE ans 8.2 EE. The extra support for dynamically reconfigured clusters has not been tested yet on 9.0. (Unit testing was done.)

3. Problem Summary

3.1. Problem Area:

8.2 only supports FOLB in static clusters. i.e. the client has to have complete idea of all endpoints that want to participate in FOLB. If new nodes are added to the cluster, existing IORs will not contain their addresses.

9.1 has support for dynamic cluster reconfiguration. A client only needs to have at least 2 endpoints specified for bootstrapping purposes in the “com.sun.appserv.iiop.endpoints” property. The server-side ORB (in all cluster instances) registers with the Group Management Service to get regular notifications of the changes in cluster shape.

3.2. Justification:

The client should not have to worry about what the cluster shape looks like. A cluster can have instances added or removed dynamically. So requests should be processed by the most current cluster shape.

4. Technical Description

4.1. Details:

This project has been completed in 9.0 and is now being carried over to 9.1. There is no extra work needed. SQE testing is all that needs to be done.

4.2. Bug/RFE Number(s):

None.

4.3. In Scope:

None.

4.4. Out of Scope:

None.

4.5. Interfaces:

4.5.1 Exported Interfaces

4.5.2 Imported interfaces

4.5.3 Other interfaces (Optional):

None.

4.6. Doc Impact:

9.0 documentation needs to be carried over to 9.1.

4.7. Admin/Config Impact:

No changes.

4.8. HA Impact:

None.

4.9. I18N/L10N Impact:

None.

4.10. Packaging & Delivery:

No impact on install/upgrade.

4.11. Security Impact:

FOLB does not work well yet with SSL. 2 bugs have been created to fix this : 6328358 & 6331551

4.12. Compatibility Impact:

None. No changes to upgrade tool and migration tool.

4.13. Dependencies:

None.

5. Reference Documents:

Reference Document	Location (i.e. URL, file, owner, etc.)
[1] IIOP LB/FO design document	http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/FODynamicCluster.pdf
[2] OMG CORBA Specification 3.02	http://www.omg.org/technology/documents/formal/corba_iiop.htm
[3] Functional Specification: RMI-IIOP Load Balancing and Failover AS 9.0 EE	http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/AS9.0-RMI-IIOP-FOLB-FS.sxw

6. Schedule:

6.1. Projected Availability:

Project is already available in main trunk (9.1).