Bug 3700

The TAO_IIOP_Endpoint::hash() operation tries to use the underlying ACE_INET_Addr::hash() value as its own. The problem with this is that a BiDirectional GIOP context can supply endpoints that are unresolvable in the receiver's context. Since the endpoint is only intended to be used as a key in the transport cache, this should be OK. 

In the current implementation, receipt of a bidir giop context containing an unresolvable address triggers a two-fold side-effect. First, because the object addr member of the associated IIOP_Endpoint is uninitialized, the hash method will attempt to initialize it. On some platforms, such as windows, this can trigger a DNS lookup which may take a second or 2 to return. Second, because the DNS lookup fails, the object addr remains uninitialized, and thus its own hash value returns 0. 

That the hash value is set to 0 means that subsequent calls, for comparisons say, go through the same initialization/failure sequence that also takes time. It also means that any such addresses fall into bucket 0. In the case where many clients contact a server via bidir, the performance of the transport cache is also impacted.

I'm not sure what the correct solution is, but I am leaning towards using a hash of the hostname string in the IIOP_Endpoint if the object addr cannot be set due to non-resolvability. This should be OK for the bidir case because one would expect the peer to use the same hostname form in the bidir context and in any IORs it sends.

Since the IIOP_Endpoint only hashes once, assuming a non-zero result, one approach to solving this problem is to try the existing algorithm, then if that fails, hash the hostname string itself. Unfortunately, during the evaluation of a IIOP_Endpoint as part of an invocation, there is no way to know that the target is part of a bidir giop connection and thus should not try to initialize the contained INET_Addr. 

Perhaps a -ORB option, either through ORB_init or one of the factories, could force the IIOP_Endpoint to always hash hostnames.