Archived

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

AMD Collocation Optimization

At our firm, we are currently using Ice to implement a number of financial service systems. We need to have a service locator that can differentiate between different versions, different locales, and different priorities. While we could implement our own locator service like the one provided with IceGrid, we would rather remove the dependency on a centralized service and employ a multicast locator strategy.

I'm aware that this discussion has been brought up before, and I agree with you. This isn't something that should be bundled with Ice. As a result, I set out to implement my own Locator that I could plug into a Proxy/Communicator to implement the desired logic. Unfortunately, something that seems so simple turned out to be far more complex.

Because this Locator is completely internal to the application and should not be reachable from outside of the process, I first created an unnamed ObjectAdapter with Communicator::createObjectAdapter(""). I registered an instance of my Locator implementation with it and got back my LocatorPrx proxy. I then created an indirect proxy to my service and set the locator to my proxy using ice_locator.

The first problem I ran into was that Ice did not detect that the Locator proxy was local and kept failing because it could not find an endpoint. I traced this down to the ObjectAdapterI::isLocal method, where it attempts to find an adapter with endpoints that match the endpoints of the proxy. However, when the proxy has no endpoints (such as mine), it will always return false. By modifying the code to return true if a) it is a direct reference, b) it has no endpoints, and c) the adapter's id is empty, I was able to get Ice to correctly recognize my Locator proxy as local.

The next problem I ran into was that not only is collocation not optimized for AMD methods, it's not implemented at all! Unfortunately, disabling collocation optimization doesn't work either, because as soon as it is disabled, Ice expects an endpoint to communicate over. Going back to my requirement that the Locator be internal and unreachable from outside the process, this isn't feasible.

So, in my quest to get this working, I implemented collocation optimization for AMD methods for C++ and C#.

It basically works by providing an alternate implementation of the AMD callback interface that uses a condition variable (Monitor on C#) to block the delegate method until the ice_response() method on the callback object has been called. The DelegateD method implementation constructs an instance of this interface and passes it to the <method>_async method of the servant. Upon returning from the servant call, the delegate will wait until the ice_response() method on the callback has been called (which may have happened in the <method>_async call). If the _async call needed to defer the response, the delegate will block, just as if it was a non-collocated call. Once ice_response() has been called (and the condition variable has been signaled), the delegate will resume and the return value and out params will be retrieved from the callback object and returned to the caller. The C++ version is futher optimized by constructing the callback object with references to the return value and out params that were passed in, and they will be filled out directly by the call to ice_response().

With this in place, I was finally able implement my collocated Locator, and it works perfectly!!

I've tried to write these patches in keeping with your style as much as possible, but given your intimate knowledge of the Ice internals, I wouldn't doubt if there is a better or cleaner way. I would absolutely love to see this implemented in the official release, as I really don't want to maintain a seperate set of patches. If you have any questions, or if there is anything I can do to help, please let me know.

Thank you,
Brett Polivka

Comments

  • marc
    marc Florida
    Thanks for the information. If you would like to have these patches integrated into future versions of Ice, please contact us at info@zeroc.com.