Interface InboundConnectionCache<C extends Connection>
- All Superinterfaces:
ConnectionCache<C>
- All Known Implementing Classes:
InboundConnectionCacheBlockingImpl
,InboundConnectionCacheImpl
This cache places minimal requirements on the Connections that it contains:
- A Connection must implement a close() method. This is called when idle connections are reclaimed.
- A Connection must be usable as a HashMap key.
Some simple methods are provided for monitoring the state of the cache: numbers of busy and idle connections, and the total number of connections in the cache.
Access is also provided to the cache configuration: maxParallelConnections, highWaterMark, and numberToReclaim. Currently these can only be set when the cache is created. XXX We may wish to make the cache configuration dynamically configurable.
-
Method Summary
Modifier and TypeMethodDescriptionvoid
requestProcessed
(C conn, int numResponseExpected) Indicate that request processing has been completed for a request received on conn.void
requestReceived
(C conn) Mark a connection as busy because a request is being processed on the connection.void
responseSent
(C conn) Inform the cache that a response has been sent on a particular connection.Methods inherited from interface com.sun.corba.ee.spi.transport.connection.ConnectionCache
close, getCacheType, highWaterMark, numberOfBusyConnections, numberOfConnections, numberOfIdleConnections, numberOfReclaimableConnections, numberToReclaim
-
Method Details
-
requestReceived
Mark a connection as busy because a request is being processed on the connection. The connection may or may not be previously known to the cache when this method is called. Busy connections cannot be reclaimed. This provides an early indication that a Connection is in use, before we know how many responses still need to be sent on the Connection for this request. This reduces the likelyhood of reclaiming a connection on which we are processing a request.Note that this problem is inherent in a distributed system. We could in any case reclaim a connection AFTER a client has sent a request but BEFORE the request is received. Note that AFTER and BEFORE refer to global time which does not really exist in a distributed system (or at least we want to pretend it is not available). XXX Should we age out connections? This would require actual time stamps, rather than just an LRU queue.
- Parameters:
conn
- connection to mark as busy
-
requestProcessed
Indicate that request processing has been completed for a request received on conn. This indicates that a Connection that received a request as indicated in a previous call to requestReceived has completed request processing for that request. Responses may still need to be sent. Some number of responses (usually 0 or 1) may be expected ON THE SAME CONNECTION even for an idle connection. We maintain a count of the number of outstanding responses we expect for protocols that return the response on the same connection on which the request was received. This is necessary to prevent reclamation of a Connection that is idle, but still needed to send responses to old requests.- Parameters:
conn
- connection to mark as completednumResponseExpected
- responses expected
-
responseSent
Inform the cache that a response has been sent on a particular connection.When a Connection is idle, and has no pending responses, it is eligible for reclamation.
- Parameters:
conn
- connection that response has been sent on
-