If the application is doing new InitialContext calls, then another way
to get load balancing behavior is to use round-robin DNS -- set up a DNS
name alias that contains the various hosts in question, and each time
the name lookup is performed, it will return a different host from that
list.
That requires turning off any OS name caching (e.g. nscd on Solaris) and
turning off the JVM name caching (using -Dnetworkaddress.cache.ttl=0
-Dsun.net.inetaddr.ttl=0 as JVM options on the client), but at least it
doesn't require application changes.
-Scott
On 08/26/09 12:53, Ken Cavanaugh wrote:
> Mark Williams wrote:
>> > 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
>> loadbalance
>> iiop targets in GFv2. The feature is FOLB (fail over load balancing)
>> meaning
>> you connect to the first target past in always. Later if that fails,
>> try the
>> next 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.
>> >
>> > http://fisheye5.cenqua.com/changelog/glassfish?cs=SJSAS91_FCS_BRANCH:mw108355:200811
>> > 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 you
>> thought, and was in fact FOLB (Fail Over Load Balancing) in which the
>> server
>> should use FIFO logic to do initial connection and then (only in a
>> fail over
>> situation) try the other connections passed in (IN FIFO order).
>>
>>
>> Out of this came the RFE request to have true load balancing of iiop
>> connections, 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
>> working
>> and the customer's (and your) misconception that GFv2 ever supported
>> iiop lb.
>>
>>
>> http://bt2ws.central.sun.com/CrPrint?id=6794941
>>
>> Work Around
>>
>> Can you go to the customer and suggest that they change their
>> application code
>> to 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't
>> they make their code do that? The system is designed to look at the
>> iiop 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
>> just
>> changing the order of the iiop connection endpoints they are supplying
>> to the
>> server when they try to connect.
>>
>> If they are creating a connection and caching it (to avoid the expensive
>> overhead 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 a
>> failover situation!
>>
>> If they are creating and tearing down the connection each time, then just
>> randomizing the iiop.endpoints property should do what they want. See
>> the 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
>> feature
>> being worked on (that doesn't exist yet...) As you can see, it's quite
>> involved.
> The PRLB implementation is in GFv2.1.1 b29 as of last week.
> It's been tested by SQE, and is now being tested by Argela (I think).
>
> Ken.
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: dev-help_at_glassfish.dev.java.net