| Summary: | Move cache related strategies to Connector Registry | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Ossama Othman <ossama.othman> |
| Component: | ORB | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | NEW --- | ||
| Severity: | enhancement | ||
| Priority: | P2 | ||
| Version: | 1.0 | ||
| Hardware: | All | ||
| OS: | All | ||
I am deferring this for now as this can be done as part of enhancements later. Library size is becoming an issue again. Let's keep this bug unresolved (i.e. do not resolve it as "deferred") so that it doesn't get lost among the rest of the bugs. *** Bug 251 has been marked as a duplicate of this bug. *** Some more notes on this:
1. With bi-directional connections, the connection cache should
definitely be removed from the Connector.
2. We need to pick connections based on policies. Therefore, we
should definitely decouple connection establishment (the connector)
from the cache. Remember, the connector currently only selects
connections based on remote endpoints and does not pay any
attention to policies.
3. As part of these changes, we should also fix the following problem
related to buffering oneways:
There might be an instance where two or more threads could try to
use the same connection simultaneously causing a new connection to
be created. We then have a potential for some queue to never be
flushed as queues are currently connection (Transport object)
specific.
One solution is to block the second thread while the first queues
the message, instead of the second thread opening a new
connection. This will require the strategization of the algorithm
in the connector, which currently opens a new connection to the
endpoint if a existing connection to the same endpoint is busy.
Another solution is two share the queue between two connections to
the same endpoint. However, this will require the addition of
locks to the queue (which will slow down the common case).
This problem is related to Bug 386 and both should be solved simultaneously. The bug is accepted and still deferred. Bala has revamped the connection caching mechanism nicely (i.e., implemented a protocol-neutral caching mechanism), so I think that we can mark this enhancement as fixed. Bala can you please confirm this? This bug has been partially fixed. I (we) need to do the following in the days before TAO 1.2 1. Add purging 2. Add a policy to make or wait on a connection I did not know that I had to accept the bug. Purging has been added. We still need to do the following Add a policy to make a thread wait for a connection or make a new connection Decide on what can be done if purging fails ie. if the purging strategy is not able to remove any connection froom the cache. IMnsHO if connection purging fails, i.e. you don't have enough resources given the current constraints then all you have to do is raise TRANSIENT. Our MUXED connection strategy is simply broken and this is a good place to start fixing that. The MUXED connection has this danger of setting up new connections all of a sudden. We want to avoid that. The best way to do that is to wait on a condition variable so that we can use connections that are freed. This should be useful for MUXED connections a lot. We may have to remove the indexing stuff within the Cache and allow collisions. Further, we may have to implement the Non_Servant Upcall trick in the POA for the Cache. If this is not done we are going to see deadlocks originating from this. to pool |
The cached connect strategies currently found in {IIOP,UIOP}_Connector should be moved to the Connector Registry since it make more sense to put them there and since doing so would aid in minimizing code bloat. The following are some ideas from Carlos and Kirthika about what should be done: Carlos: + We should isolate the caching in the Connector_Registry or the ORB itself, there is no sense in having separate caches for each protocol. Kirthika: * yup, that had to be done as of now since there is no common place where they can be put such that they get universally used by all the different protocols. If suppose the protocols themselves have a helper class with all the common code amongst them , then the caching could easily fit in there. Carlos: + The caching mechanism should be implemented in terms of Transport objects so new protocols get caching "for free". + The recycling strategies should do the same. Kirthika: * This sounds good, so long as we are able to be able to cache the handlers with caching tags so that they can be purged/ recycled later according to different caching strategies (eg. LRU). But I remember that you felt that the connection cache itself should be removed from the Cached_Connect_Strategy and got into transport. Then, yes, teh picture changes totally.