Archived

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

proxy loses custom locator

A function retrieves a proxy using a given id. The proxy has a custom locator assigned (ice_locator).
However, on return the locator property is missing which ultimately results in a "no suitable endpoint available" exception.

The function:

ObjectPrx CViaTCALocator::VIATCAFindObjectById(const string& Id, const Current& /*= ::Ice::Current()*/) const
{
OBJECT_SYNCHRONIZE

ObjectPrx TheObject(0);

string TheId = VIATCAFindUrpIdById( Id );

if( !TheId.empty() )
{
GetInterface( TheId, TheObject, GET_INTERFACE_TIMEOUT );
}

return TheObject;
}

OBJECT_SYNCHRONIZE : locks instance of CViaTCALocator
VIATCAFindUrpIdById : maps functional name (Id) to object identity (TheId)
GetInterface : retrieves proxy from cache or creates new one (ic->stringToProxy) and sets our custom locator (prx->ice_locator). Proxy is returned in TheObject

The proxy "TheObject" is obviously passed by reference where the function itself returns a local variable (and implicit copy). We would have expected the exact same behaviour, but alas it has not.

We would really like to understand why this fails.

Comments

  • dwayne
    dwayne St. John's, Newfoundland
    The locator is a local setting and is not marshalled when the proxy is transferred over-the-wire. The only proxy information that a marshalled proxy may contain is the identity, facet, invocation mode, adapter id and endpoints. All other proxy properties are local. Proxies are explained in detail in this newsletter article.
  • Is my understanding correct that a copy of any proxy loses the properties of the proxy. I.e. always makes a non local proxy?

    Thing is that an interface may return a proxy of an object, but cannot include a designated locator. How would the client then find out which locator to use?
    Obviously we do not want to configure this.

    An indirect proxy requires some locator to resolve the endpoints, so the locator property seems 'somehow part of' the indirect proxy.

    How would you solve this?

    NB I will catch up with my reading.
  • dwayne
    dwayne St. John's, Newfoundland
    timruijs wrote: »
    Is my understanding correct that a copy of any proxy loses the properties of the proxy. I.e. always makes a non local proxy?

    A proxy which is passed remotely through a Slice interface will not include the local settings. You can copy proxies locally without losing the local settings.
    timruijs wrote: »
    Thing is that an interface may return a proxy of an object, but cannot include a designated locator. How would the client then find out which locator to use?
    Obviously we do not want to configure this.

    An indirect proxy requires some locator to resolve the endpoints, so the locator property seems 'somehow part of' the indirect proxy.

    How would you solve this?

    If it is necessary in your application for the client to obtain the locator from the server then you can just return the locator proxy in the same call that you use to obtain the regular proxy. Then in your client you would set the locator on the returned proxy.

    Or depending on how your application works it might only be necessary to retrieve the locator once and then just use it to either set the default locator in the client or set the locator on proxies returned from subsequent calls.
  • I have read issue 19/23 on proxies.
    dwayne wrote: »
    A proxy which is passed remotely through a Slice interface will not include the local settings. You can copy proxies locally without losing the local settings.
    In the example code above the proxy is copied (e.g. as return value) of a local function, but appears to lose the locator setting.
    dwayne wrote: »
    If it is necessary in your application for the client to obtain the locator from the server then you can just return the locator proxy in the same call that you use to obtain the regular proxy. Then in your client you would set the locator on the returned proxy.

    Or depending on how your application works it might only be necessary to retrieve the locator once and then just use it to either set the default locator in the client or set the locator on proxies returned from subsequent calls.
    This implies to defer the responsibility to use a designated locator to the client. However, it is a clean approach I will certainly will look into.
  • dwayne
    dwayne St. John's, Newfoundland
    timruijs wrote: »
    I have read issue 19/23 on proxies.
    In the example code above the proxy is copied (e.g. as return value) of a local function, but appears to lose the locator setting.

    Returning a proxy from a local C++ function call should not cause any of the local setting to be lost. If you could provide a small, complete example that shows the behavior you are seeing, we would be happy to look into it.
  • :o found the cause.The function is actually an implementation of an interface and thus returns a proxy 'on the wire', which loses its properties.
    The Ice::Current in the parameter list should have been a dead give away, but we have simply overlooked it and assumed a regular C++ class method.

    We will look into your suggestion to also return the locator to be used with the indirect proxy.
    As always you have been very helpful ;)