Archived

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

ice_getEndpoints returns empty

Why IndirectProxy->Ice_getEndpoints() returns a empty vector?

I want to get the endpoints of a replica group. and decide which to use manually.

IceGrid::Admin have this ability but I think it is a security risk open this for the client. While if create a new service to choice among endpoints, this new service will faces performance problem.(maybe I can replica this new service as well??)

If the IndirectProxy->ice_getEndpoints() works like DirectProxy, this will never be a problem.
Do you have any special consideration of disable this interface?
I want to do some patches make it work. What I must pay attention to?

Comments

  • benoit
    benoit Rennes, France
    Hi,

    The ice_getEndpoints() method returns the endpoints of the proxy, since an indirect proxy has no endpoints, it returns an empty sequence of endpoints.

    Why do you need to get the endpoints of each replica? Is this to create proxies for each replicated object? I'm afraid there's currently no way to retrieve the individual proxies of each replicated object, adding such a method is on our TODO list however!

    Cheers,
    Benoit.
  • Thank you Benoit!!

    A description of my application might be useful for understanding why I need to getEndpoints on replica group.

    There are 10,000,000 records in the database. The application needs query and update 30% of these records frequently. This make difficult for my database app.

    So I use Ice as base of middle-layer. Each line of records maps to a servant. And I have about 3,000,000 servants. I want these servants keep in memory to speed up query, and I can update the database in a background thread.
    If each servant needs 100KByte of memory, 3,000,000 servants will take 300GByte.
    I have to put these servants in hundreds of nodes.

    This causes the problems I recently posted here. I have to find a servant by it's ID directly. At the same time, one nodes halt must not be seen by the client.

    Current replica modes are stateless but I need a stateful one.

    The best ways I found is:
    a) Like Connections Issue 10 said, create a registry service to manage a table.
    b) No replica group. Use ID % adapter_num to choice adapters.

    Solution (a) faces a bottleneck of the registry. And if using replicated registry, sync the table among them will be complex.
    Solution (b) is very simply and have no bottleneck. But client must know each of the adapters and the total count of adapters. AND when a node halt, 1/adapter_num of users will receive exception.
    I have thought create a backup adapter using replica group,
    (like this:http://www.zeroc.com/vbulletin/showthread.php?t=2726)
    but create hundreds replica group in XML is really really difficult.

    Then this is why I want to getEndpoints on a replica group.
    I want to use solution (b) and put these adapter in a replica group. replica group will take over the fault tolerant. Client has a policy of choosing ordered endpoints by ID. So So So, getEndpoints.

    I found that endpoins is exists in IceGrid/LocatorI.cpp. LocatorI create a dummy:default proxy for each adapter and return them to the client.
    I don't find where the client choose endpoints between them.
    If it's possible, I prefer changing one or to line of Ice's source to make it work.

    Hope my English confuse nobody.:p
  • benoit
    benoit Rennes, France
    Sounds like an interesting and challenging application! Again, I would recommend you to consider purchasing support or consulting services if you need help with the design or the scalability issues of your application -- as I explained in my other post, such specific questions are out of the scope of the free support we can provide on the forums.

    To answer your question on how the Ice client runtime chooses the endpoints returned by the locator for the replica group: take a look at the documentation of the ice_endpointSelection() proxy method in the Ice manual. The endpoint selection type (random or ordered) determines how the Ice client runtime will choose the endpoint to establish a connection.

    Cheers,
    Benoit.