In Process Request.

[luuma]

Sorry for my poor English...

I am in developing a huge network system. We use ICE as our network
component library. Some component in our system is distributed among
sever computers. Components who work extensively requiring each
other couple tightly in one process for reaching maximun speed. I track
the example calling path for local request in ICE:

1 . Invoking the proxy call 'op'
-------------------------------------------------------------------
::IceInternal::Handle< ::IceDelegate::Ice::Object> __delBase =
__getDelegate();
::IceDelegate::Filesystem::Node* __del =
dynamic_cast< ::IceDelegate::Filesystem::Node*>(__delBase.get()) ;
return __del->name(__ctx);
-------------------------------------------------------------------
2 . Calling to __getDelegate()
-------------------------------------------------------------------
Handle< ::IceDelegate::Ice::Object> delegate;
if(_reference->getCollocationOptimization())
{
ObjectAdapterPtr adapter = _reference->getInstance()->
objectAdapterFactory()->findObjectAdapter(this);
if(adapter)
{
Handle< ::IceDelegateD::Ice::Object> d = __createDelegateD();
d->setup(_reference, adapter);
delegate = d;
}
}
-------------------------------------------------------------------
3 . In delegate method
-------------------------------------------------------------------
::IceInternal:irect __direct(__current);
::Filesystem::Node* __servant = dynamic_cast< ::Filesystem::Node*>
(__direct.servant().get());
if(!__servant)
{
::Ice::OperationNotExistException __opEx(__FILE__, __LINE__);
__opEx.id = __current.id;
__opEx.facet = __current.facet;
__opEx.operation = __current.operation;
throw __opEx;
}
try
{
return __servant->name(__current);
}
---------------------------------------------------------------------
4 . Get Direct Object , find the servant on the fly.
---------------------------------------------------------------------
ServantManagerPtr servantManager = adapter->getServantManager();
assert(servantManager);
try
{
_servant = servantManager->findServant(_current.id, _current.facet);
---------------------------------------------------------------------
5 . Do actual calling on the servant.


The calling path is very clear and straight forward. BUT there
is no optimization at all for local object locating except the
marshaling processing.

I look the COM model . COM M has local method invoking
accelaration. So the in process server is fast enough to replace
some old style C++ DLL Library for maximun flexibility.

Could ICE adds some mechanism for fast local object request??
We need your help.

[marc]

Welcome to our forums!

Please see this thread regarding our support policy.

[luuma]

I am sorry to confuse you:
The post refers to only my advisement , no service or question asked.

[matthew]

I think you misunderstand. If you want us to answer your question you must fill in your signature information.

[luuma]

ok , check.

[matthew]

If the servant and client are collocated Ice does have a collocation optimization in that while the data itself is actually marshaled and demarshaled, no data actually flows over any network.

While it is possible to do away with the data marshaling under some circumstances it is actually very complex to do so AND preserve location transparency (that is the server cannot distinguish between a local call and a remote call). Because its very complex, and only useful under a very limited set of circumstances we don't view this use-case as very important we have not implemented this.

[luuma]

I studied many component frameworks (CORBA , []COM , ICE , ...) , found the MS COM or XPCOM having the best local call efficiency .

Some component sometimes is wrapped in a DLL module for maximun speed , for example the famous DIRECTX. The MS DIRECTX has well-design object model , so the users can using or porting there programs easily.

In my opinion , component framework is not only related to CROSS PROCESS OR CROSS COMPUTER . But the user can seperate their software design into small piece that has loose connection . The local call speed is very important to some critical operation or atomic operation , because these operations are having be called some many times.

Sometimes , we should have to make choice to make the component blackbox bigger and bigger due to SPEED at all.

[matthew]

Actually, I'm wrong. If the collocation optimization can be used no data is marshaled. If you want to see the details look at the IceDelgateD classes in the generated code for an example.

[luuma]

en....

My first post at this thread shows the path that makes a local call . I mean that path is tooo long and tooo slow. The implemention is optimized actually, but far from acheiving the best performance.

I check the DelegateD class and their derivers very carefully , here giving my advisement on this:

FILE: hello.cc
--------------------------------------------------------------------
void
IceDelegateD:emo::Hello::sayHello(const ::Ice::Context& __context)
{
::Ice::Current __current;
__initCurrent(__current, __Demo__Hello__sayHello_name, ::Ice::Nonmutating, __context);
while(true)
{
::IceInternal:irect __direct(__current);
:emo::Hello* __servant = dynamic_cast< :emo::Hello*>(__direct.servant().get()); if(!__servant) ...
try
{
__servant->sayHello(__current);
return;
}
catch(const ::Ice::LocalException& __ex)
{
throw ::IceInternal::LocalExceptionWrapper(__ex, false);
}
}
}
----------------------------------------------------------------------

The red code indicates that the servant will be found at every call , I think adding a caching servant member will accelerate execution speed dramaticlly while a lot of object staying in the object adpter.

Am I right?

[marc]

You cannot cache the servant, as this would break location transparency. For example, if you use Freeze (or other servant locators) in collocated applications, this wouldn't work.

Location transparency is essential for Ice, even for collocated calls. COM does not have any such concept, therefore you cannot really compare Ice and COM. If you need very fast local calls, then you should call the servants directly, without using proxies.

[luuma]

I known the limitation of caching physology. But in almost all programs , the local base support component is always in DLL form. There is no reason to run it in another process or computer and NO LOCATOR OR RECATOR needed.

Once object proxy is initialled we could determine whehter it is a local object . To some critical object we could specialfy this proxy has permant destination in some method in manner. OR we could create the proxy using another function like "IdentityToProxyPermant"... simply.

The benefit of this is that we could invoke method on an universal interface.

[marc]

Sorry, but you are incorrect. A servant is not an Ice object. However, a proxy refers to an Ice object, not a servant. A servant incarnates Ice objects, and such incarnation can change over time. For example, a servant could be loaded on demand with a servant locator, be discarded after each request, etc. For more information, have a look at the Ice manual, and this FAQ.

Again, both the Ice object model and location transparency are inherent and substantial to the design of Ice. Of course you could design a middleware architecture without these concepts, which would allow you to have better collocation optimization, but at the expense of flexibility and scalability. But this is not what Ice is about. If you need such other middleware architecture, which is more COM-like, then Ice is simply not the right solution for your project.

[luuma]

OK , I love ICE at my first sight. And the COM is sticked to MSWIN , so it is only a MS toy.

We will insisit to using it in our project. For special objects we could modify the delegateD code to meet our need. I think this is the best way to handle the collocated call.

Thank you very much.

[michi]

I would suggest that you benchmark the performance for collocated calls before making any far-reaching design decisions. Basically, collocated calls are bloody fast already and chances are that you will find the performance more than adequate, unless you invoke a very large number of operations that do essentially no work in the operation body.

Also, there is nothing to stop you from calling directly into a servant (via it's Ptr, instead of via its Prx). Doing this is exactly as fast as a virtual function call (because that's what it is).

Cheers,

Michi.

[luuma]

For maximum speed , we could use ObjectPtr . For maximum portable , we must use ObjectPrx.

En ... Could we derive the ObjectPrx to incarnate a real ObjectPtr , named "ObjectPrxD". Hehe.

Sometimes , the balance is a trick.