Archived

This forum has been archived. Please start a new discussion on GitHub.

Two function conflict ?

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

Comments

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

    Cheers,
    Bernard
  • 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
    benoit Rennes, France
    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.
  • 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!