The present protocol within the cache manager is not at all suitable for any 
strict policy (like max cache size and max muxed connections) enforcement. A 
test case will be attached, thanks to Simon McQueen, which shows this problem. 
This doesnt show up in normal MT use cases

Problem:
--------
Thread making an invocation first checks in the cache and if the lookup fails 
the thread goes to create a new connection trying to purge old connections in 
the process. In MT scenario as shown in the patch, it could happen that all 
threads check in the cache more or less in the same time and go to create more 
connections. The policies that are applied may have no effect on them. This 
could be wrong. 

Solution:
---------
Slight change in the existing protocol: The invocation thread on a failed 
lookup for existing connections should not return empty handed, but create a 
dummy entry but leave the entry as busy. Once an entry is created it is easier 
to enforce these policies -- like say we could purge after the entry is created 
and do the rest of the work like making a connection. This would be easier, 
since the thread  could collect all the entries that need purging and then 
release the cache lock, do the purging outside the context of the cache lock 
and go ahead to do the remote connection.

The only catch here is to release the entry properly when connection 
initialization has failed. 

Will attach the test case in the next checkin. BTW, this would require changes 
to the interface and can be taken up only after x.3.1