The PRLB implementation is in GFv2.1.1 b29 as of last week.> Hi,>> In GFv2, EJB requests could be load balanced by passing multiple targets> in the Hashtable parameter when instantiating InitialContext. (The> targets would be randomized by rrPolicy.setClusterInstanceInfo).Not true. There was never any supported feature to randomize or loadbalanceiiop targets in GFv2. The feature is FOLB (fail over load balancing) meaningyou connect to the first target past in always. Later if that fails, try thenext in the list, and so on until you get a new connection or fail.>> In GFv2.1 this does not happen anymore because of the following change> by Mark in S1ASCtxFactory.java.>> 25184850>> Is there any particular reason for not doing the randomizing any more?>Yes there is.The functionality you thought was IIOP load balancing did not work as youthought, and was in fact FOLB (Fail Over Load Balancing) in which the servershould use FIFO logic to do initial connection and then (only in a fail oversituation) try the other connections passed in (IN FIFO order).Out of this came the RFE request to have true load balancing of iiopconnections, a feature that does not exist yet.See RFE 6794941 for IIOP LB and failover under GF cluster"Engineering has agreed to implement another version of load balancing,which we will refer to as per-request load balancing for stateless session beans."Here is the technical explanation from the original bug about FOLB not workingand the customer's (and your) misconception that GFv2 ever supportediiop lb.Work AroundCan you go to the customer and suggest that they change their application codeto present the iiop.endpoints to the server in the order *they* want to connect to?If they want to randomly connect to host1:iiop and to host2:iiop, why don'tthey make their code do that? The system is designed to look at theiiop connection string in FIFO order, and fail over ONLY on a connection error.If they want to change the order to "load balance" they can do that by justchanging the order of the iiop connection endpoints they are supplying to theserver when they try to connect.If they are creating a connection and caching it (to avoid the expensiveoverhead of creating and tearing down the iiop endpoint connection each time)then they don't even want to connect to different iiop hosts except during afailover situation!If they are creating and tearing down the connection each time, then justrandomizing the iiop.endpoints property should do what they want. Seethe below example made from their sample code.C:\temp>c:\bin\diff -u sample_code.txt lb_sample_code.txt--- sample_code.txt Thu Jan 29 12:29:38 2009+++ lb_sample_code.txt Thu Jan 29 12:29:28 2009@@ -1,10 +1,19 @@public static void main(String[] args) throws ServletException, IOException {+ boolean coinflip = false; // variable to make client "load balance"for (int i = 0; i < 100; i++) {try {Properties props = new Properties();- props.put("com.sun.appserv.iiop.endpoints",+ // change the order of iiop.endpoints based on the flip of a coin+ if (coinflip) {+ props.put("com.sun.appserv.iiop.endpoints","192.168.0.212:33700,192.168.0.218:33700"); // 212 failover to 218+ coinflip = false;+ } else {+ props.put("com.sun.appserv.iiop.endpoints",+ "192.168.0.218:33700,192.168.0.212:33700"); // 218 failover to 212+ coinflip = true;+ }Context ic = new InitialContext(props);Here is Ken's full blown specifications for the IIOP load balancing featurebeing worked on (that doesn't exist yet...) As you can see, it's quiteinvolved.