(In reply to comment #0)
> when the transport cache will purge connections, it searches for idle ones with
> the lock hold, then it sets the transport to busy.
> 
> after going through all the transports it releases the lock and then closes the
> transports that it wants to purge. after the lock is released it could happen
> that a transport is used for making a new connection before it gets purged.

I don't understand what you mean by "a transport is used for making a new
connection."  Do you mean used for making a new invocation?  If the transport
is already in the cache, then the connection already exists.  A new connection
would result in a new entry in the cache.

> at
> that moment the close will close a transport which is used for making an
> invocation and then the caller gets a transient back.

Perhaps the cache entries need a new state, such as PURGE_IN_PROGRESS.
Then, when the cache is being searched for a suitable transport for sending
an invocation, any transport in the PURGE_IN_PROGRESS state would be ignored.

Either that, or entries to be purged could be removed from the cache while the
lock is held and copied to a special purge list.  Then, the lock could be
released and the purging logic could safely close the connections on the
purge list.

Thoughts?

Steve

(In reply to comment #1)
> (In reply to comment #0)
> I don't understand what you mean by "a transport is used for making a new
> connection."  Do you mean used for making a new invocation?  If the transport
> is already in the cache, then the connection already exists.  A new connection
> would result in a new entry in the cache.

I meant a new invocation

> > at
> > that moment the close will close a transport which is used for making an
> > invocation and then the caller gets a transient back.
> 
> Perhaps the cache entries need a new state, such as PURGE_IN_PROGRESS.
> Then, when the cache is being searched for a suitable transport for sending
> an invocation, any transport in the PURGE_IN_PROGRESS state would be ignored.

Or when the transport is in that state, it is set to busy and used, but then not purged

> Either that, or entries to be purged could be removed from the cache while the
> lock is held and copied to a special purge list.  Then, the lock could be
> released and the purging logic could safely close the connections on the
> purge list.
> 
> Thoughts?

I can reproduce it now with but 3543 regresssion with 1000 clients and 20 threads. It seems this got introduced with the cache refactoring of last summer, with 1.6.1 it seems to run

mine

has been fixed