Two function conflict ?

rc_hz

It seems that the two functions of ObjectPrx conflict:

int status = 0;
Ice.Communicator ic = null;
try {
    ic = Ice.Util.initialize(args);
    Ice.ObjectPrx base = ic.stringToProxy(
    	"SimplePrinter:tcp -h 10.10.10.1 -p 10001:tcp -h 10.10.10.1 -p 10000");

    base = base.[COLOR="Blue"]ice_endpointSelection(Ice.EndpointSelectionType.Ordered)[/COLOR];
    base = base.[COLOR="blue"]ice_connectionCached(false)[/COLOR];
    
    Demo.PrinterPrx printer = Demo.PrinterPrxHelper.uncheckedCast(base);

    while (true)
    {
	Scanner in = new Scanner(System.in);
	System.out.print("Input something to start the continue:");
	String name = in.nextLine();
		
	if (name.compareTo("exit") == 0) break;
    	printer.printString("I am testing");
    }
}
//...

The requests always go to (tcp -h 10.10.10.1 -p 10001) and never go to (tcp -h 10.10.10.1 -p 10000).

BTW, my environment:

IceJ 3.1.1
Windows XP
java 1.5

bernard

That's the intended behavior: when the endpoint selection is ordered, Ice prefers the first endpoint.

Cheers,
Bernard

rc_hz

bernard wrote: »

That's the intended behavior: when the endpoint selection is ordered, Ice prefers the first endpoint.

As we know, ice_connectionCached(false) is used to force load balancing to use all available endpoints. By using ice_connectionCached(false) and ice_endpointSelection(Ice.EndpointSelectionType.Ordered) together, I think the requests will go to (tcp -h 10.10.10.1 -p 10001) and (tcp -h 10.10.10.1 -p 10000) in turn. This seems more rational:)

If I change the above code:

    base = base.[COLOR="blue"]ice_endpointSelection(Ice.EndpointSelectionType.[B]Random[/B]);[/COLOR]
    base = base.[COLOR="blue"]ice_connectionCached(false);[/COLOR]

or just

    base = base.ice_connectionCached(false);

The requests will go to (tcp -h 10.10.10.1 -p 10001) and (tcp -h 10.10.10.1 -p 10000) randomly.

benoit

rc_hz wrote: »

By using ice_connectionCached(false) and ice_endpointSelection(Ice.EndpointSelectionType.Ordered) together, I think the requests will go to (tcp -h 10.10.10.1 -p 10001) and (tcp -h 10.10.10.1 -p 10000) in turn. This seems more rational:)

What you're describing here would be an new endpoint selection type: a round robin endpoint selection type. Ice doesn't support this right now.

Using the ordered endpoint selection type with connection cached set to false can be useful in a scenario where you have a primary server with a secondary failover server. In such a scenario if the main server is unavailable, Ice will connect to the secondary failover server. As soon as the main server is available again, Ice will re-connect to it (if connection caching was enabled the proxy would continue to invoke on the secondary server).

Cheers,
Benoit.

rc_hz

I understand now, thank you very much.

benoit wrote: »

Using the ordered endpoint selection type with connection cached set to false can be useful in a scenario where you have a primary server with a secondary failover server. In such a scenario if the main server is unavailable, Ice will connect to the secondary failover server. As soon as the main server is available again, Ice will re-connect to it (if connection caching was enabled the proxy would continue to invoke on the secondary server).

Really wonderful!