Message6142

OK, there is definitely a memory leak going on here. I'm seeing approx 4 megabytes being used per 1000 requests.

Although it is the case that methods on an individual socket tend to only be called from a single thread, that is not guaranteed, and sockets should be thread-safe, just in case.

I tried the using an AtomicInteger for the reference_count, as Jim suggested, but wasn't hopeful that it would solve the problem. My reasoning was that the code cited, i.e. the one without synchronization, is from the _fileobject wrapper class, which is not used in this circumstance. The close() method on socket objects *is* protected by a lock, i.e. _sock.close_lock. 

Nonetheless, I made the change, to see if it would fix the error: it didn't.

Next up, I looked at the _active_sockets set, which looks like a prime candidate for concurrency problems, because A: it is a module global and B: the add(), remove() and copy() operations carried out on it are not atomic (on jython, AFAIK). So I wrapped a synchronized.apply_synchronized() call around those operations, in the hope that this would cure the problem: it didn't :-(

In the interest of completeness, I attach a patch against trunk for the solutions I tried.