Question about proxy's factory methods.

rc_hz

As Ice Manual says:

Proxy's methods can be categorized as follows:
  ...
  Factory: methods that return new proxy instances configured with different features.
  ...

In my view, since these factory methods return new proxy instances, these new proxies should manage their own connections (establish a new connection, reuse an existing connection, etc) at their first invocation, which don't need to have relations with their previous proxy.
However , in the example:

//we configure the Client: Ice.RetryIntervals=-1

//timeA: Client get a proxy and establish a connection
HelloPrx twoway = HelloPrxHelper.checkedCast(communicator().stringToProxy("Hello"));
twoway.ice_ping();
twoway.sayHello();

//timeB: Server close the connection gracefully.
...


//timeC: Client get a new proxy with the help of factory methods:
HelloPrx another1 = HelloPrxHelper.uncheckedCast(twoway.ice_compress(false));
HelloPrx another2 = HelloPrxHelper.uncheckedCast(twoway.ice_timeout(-1));
HelloPrx another3 = HelloPrxHelper.uncheckedCast(twoway.ice_timeout(1000));
HelloPrx another4 = HelloPrxHelper.uncheckedCast(twoway.ice_secure(true));
HelloPrx another5 = HelloPrxHelper.uncheckedCast(twoway.ice_connectionId("JustForTest"));

//timeD: get a invocation from these new proxies:
anotherX.ice_ping();	//X=1,2,3,4,5

At timeD, the invocation on new proxies all gets an exception of CloseConnectionException. It seems that they all reuse the connection of "twoway" proxy instead of establish a new connection. Is it strange ?

Thank you!

marc

Connection reuse is intended behavior. I do not find this behavior strange, but logical. If you do not wish to reuse connections, use ice_connectionId(). Please see the manual, section "34.3.2 Connection Reuse" for details.

matthew

Hi Eric,

I've been looking into your problem and I cannot duplicate it. What I expect to happen is that twoway, another1 and another2 will share a connection. another3, 4 & 5 will all get their own connections (as described in the Ice manual). You should not get an exception because the connection is closed gracefully by the server.

I modified the hello demo that comes with the Ice for java distribution more or less as you do above:

        HelloPrx twoway = HelloPrxHelper.checkedCast(
            communicator().stringToProxy(proxy).ice_twoway().ice_timeout(-1).ice_secure(false));
        if(twoway == null)
        {
            System.err.println("invalid proxy");
            return 1;
        }
        HelloPrx p1 = HelloPrxHelper.uncheckedCast(twoway.ice_compress(false));
        HelloPrx p2 = HelloPrxHelper.uncheckedCast(twoway.ice_timeout(-1));
        HelloPrx p3 = HelloPrxHelper.uncheckedCast(twoway.ice_timeout(1000));
        HelloPrx p4 = HelloPrxHelper.uncheckedCast(twoway.ice_secure(true));
        HelloPrx p5 = HelloPrxHelper.uncheckedCast(twoway.ice_connectionId("JustForTest"));

Pressing 't' sends twoway, '1' uses p1, etc. I modified the configuration to set Ice.RetryIntervals to 1. Then I ran the server and client with network tracing so I could see what connections are being used. The result is as expected.

t
[ Network: tcp connection established
  local address = 127.0.0.1:50614
  remote address = 127.0.0.1:10000 ]
==> [ Network: closing tcp connection
  local address = 127.0.0.1:50614
  remote address = 127.0.0.1:10000 ]
1
[ Network: tcp connection established
  local address = 127.0.0.1:50615
  remote address = 127.0.0.1:10000 ]
==> 2
==> 3
[ Network: tcp connection established
  local address = 127.0.0.1:50616
  remote address = 127.0.0.1:10000 ]
==> 4
[ Network: ssl connection established
  local address = 192.168.1.107:50617
  remote address = 192.168.1.107:10001 ]
[ Network: ssl connection established
  local address = 192.168.1.107:50617
  remote address = 192.168.1.107:10001 ]
==> 5
[ Network: tcp connection established
  local address = 192.168.1.107:50618
  remote address = 192.168.1.107:10000 ]
==> 

I don't know why my results differ to yours. If you want me to look further please give me much more information. Ice version, platform, JDK version and a complete self-contained compilable demo.

rc_hz

Thanks, matthew and Marc.

I have found what's wrong with my code. In my code, the "twoway" proxy is a fixed connection proxy as following:

[COLOR="blue"]twoway[/COLOR] = HelloPrxHelper.uncheckedCast(
      orig.ice_getConnection().createProxy(...));

So the new proxies returned from these proxy factory methods are also fixed connection proxies which use the same connection as "twoway". If the connection is lost, these new proxies can not work either.

The attachment is a self-contained example. (JDK5.0, Ice3.1, Windows XP SP2).

Thanks again!

rc_hz

This is the attachment.

rc_hz

Further test shows that these proxy factory methods(ice_timeout/ice_connectionId/ice_secure) have no impact on a fixed connection. For example(Change a little the code in the above attachment) :

// -- Client.java --

// 1.a common proxy
HelloPrx original = HelloPrxHelper.checkedCast(
			communicator().stringToProxy(proxy));					
// 2.a fixed connection proxy
HelloPrx twoway = HelloPrxHelper.uncheckedCast(
	original.ice_getConnection().createProxy(original.ice_getIdentity()));

// 3.
twoway.sayHello();

Thread.sleep(3000);

// 4. get new proxies by proxy factory methods
HelloPrx another = HelloPrxHelper.uncheckedCast(twoway.ice_timeout([COLOR="Blue"]1000[/COLOR]));

// 5. invocate these new proxies and get CloseConnectionException exception
// [COLOR="Blue"]Attention: the invocation doest not timeout![/COLOR]
another.sayHello();

// -- HelloI.java --
    sayHello(Ice.Current current)
    {    	
    	try
    	{
    		//current.con.close(false);    		
    		Thread.sleep([COLOR="blue"]3000[/COLOR]);
        }
        catch (Exception ex)
        {
        	ex.printStackTrace();
        }
    }

The same are ice_connectionId and ice_secure.

marc

You are correct, once a proxy has a fixed connection, it will never change, regardless of whether you change the timeout, switch it to secure, etc. I guess an exception would be more appropriate instead of silently ignoring the request. We will put this on our todo list.

rc_hz

marc wrote:

...I guess an exception would be more appropriate instead of silently ignoring the request...

I think so:)