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

scalability : help I'm confused. factories on both sides and managers on both sides ?

Hi there,

I have this situation :
I am creating objects on both sides of the network link - I have factories on both sides to do that. I need these objects as proxies on the other sides of the network link.

This works well for the case of one connection. But let us say that I now have two connections and am replicating this procedure ... it fails ...

here is what I do ...


On the endpoint :
I create my communicator, factory, adapter, servant - activated with "property1" and its running.

On the originating side (endpoint with IP address property) :
I create my communicator
I am creating my servant proxy - it uses propertyToProxy with id "property1"
Create my factory, and get my remote object using my servant.



Now I have to get originating side objects back over to the endpoint. So I proceed like so :

On the originating side :
2a - I create my local servant.
2b - I create a new adapter with property2.Control.Endpoints=tcp -p 20000:udp -p 20000:ssl -p 20001
2c - I add the servant with id "property2" to the adapter
2d - I activate my adapter.

On the endpoint :
I get my servant proxy using propertyToProxy with the id "property2.Proxy" - note property2.Proxy =property2:tcp -h flatmax -p 20000:udp -h flatmax -p 20000:ssl -h flatmax -p 20001
I can now generate my object proxy for the object which was created on the originating side.


All good ... I can run without problems - as long as there is only one connection.

Now lets get scalable ....

I have a second system and I complete the task as above ...
The first system connects as expected.

The second system fails to connect like so :
I ensure that the properties of STEP1 target the correct IP address and it connects just fine.
When I execute STEP2, the system fails at the point where I try to create the adapter - that is STEP2 2b described above.

the error message is :

terminate called after throwing an instance of 'Ice::SocketException'
what(): Network.cpp:1104: Ice::SocketException:
socket exception: Address already in use

Is the problem that both systems are targeting the same socket on the same port ?

Is there a better way to do what I am trying to do ?



  • benoit
    benoit Rennes, France

    You can't have 2 object adapters listening on the same port on the same machine. You need to define different ports for your second server instance if it's intended to run on the same machine.

    To create a proxy that points to a replicated Ice object hosted by both server instances you will need to specify the endpoints of both object adapters in the proxy endpoints.

    So for example:
    • if the object adapter #1 endpoints are tcp -h foo -p 12000:ssl -h foo -p 12001
    • and the endpoints of object adapter #2 are tcp -h foo -p 13000:ssl -h foo -p 13001

    Clients can use the following proxy to invoke on the replicated Ice object "myObject" which is hosted by both objects adapters: myObject:tcp -h foo -p 12000:ssl -h foo -p 12001:tcp -h foo -p 13000:ssl -h foo -p 13001.

    As you can imagine creating those proxies from strings or properties can quickly become cumbersome and it isn't very flexible. Fortunately, there are solutions to this.

    Firstly, you should avoid creating proxies from strings or properties... typically an Ice client creates very few proxies from strings or properties. It only creates proxies for few Ice "root" objects which then allow to obtain proxies for other Ice object through Slice interfaces (e.g.: the Slice method Hello* getHelloObject() returns a proxy for an Ice object implementing the Hello interface).

    Then, Ice applications with few servers quickly move to use the IceGrid service which allows to reduce the complexity of the endpoint configuration (no more need to specify fixed ports). IceGrid also facilitates the configuration of replicated servers with replica groups. When using IceGrid, Ice clients only need to configure a single stringified proxy (the Ice.Default.Locator proxy). Other proxies can be specified using symbolic names (e.g.: myObject @ myAdapter).

    If you are new to Ice, I strongly recommend going through the Ice manual and the demos to get a good idea of the possibilities offered by Ice and its services. I wouldn't recommend diving into IceGrid just yet, it's better to first understand the basics of Ice clients and servers :).