Harald Barth wrote: >>Harald: >> >>I wonder if this condition is a side effect of the bug that has been >>fixed by >> >> DELTA STABLE12-rx-makecall-race-fix-20050518 > > > Hi, thanks, but I have a feling that it is older because I have the > same behaviour against a server with 1.3.77 > > 1.3.77 has rx.c 1.58.2.4 and rx-makecall-race-fix-20050518 was introduced > with 1.58.2.18.
DELTA STABLE12-rx-makecall-race-fix-20050518 fixes a bug that has existed since the beginning of time. >>With this bug the rx_connection objects on one side can be destroyed >>while they are in use. New rx_connection objects would then need to >>be established. > > > I'm still fumbling in the rx-dark. Anyone got the bestseller "the life > and death of an rx connection"? Is there a way to get rid of these > zillions of connections? Am I the only one seeing this? > > And I still don't know if this is related to the sudden "server > down" problems I have to start with. > > Harald. Last October/November we fixed a large number of bugs related to rx connection objects being mismanaged due to an inability of applications which use rx to reference count the rx_connection objects. This meant that although internally the rx library was thread safe, a single rx_connection object could not safely be used by multiple threads in the application. In 1.3.72 we added the ability to reference count the rx_connection objects and in turn removed the premature destructon of the objects while in use that we had been seeing. We have also seen huge number of connections being produced by the Windows clients. The Windows clients were creating connections, using them once, and then destroying them. Most of these Windows client bugs were fixed in 1.3.72 and one more was fixed in 1.3.80. Having multiple connections from a client is not necessarily a problem. If the connection properties are different, there will need to be separate connections. It is also possible that you will have connections in the hash table that are marked as DESTROYED that have not been cleaned up yet. I'm not sure that your script produces the results you are expecting. Do you have any other information you can provide on your server down problem? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
