Message11821

Author jeff.allen
Recipients amak, crankycoder, fwierzbicki, jeff.allen, treaves, zyasoft
Date 2018-03-17.10:55:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1521284147.88.0.467229070634.issue1761@psf.upfronthosting.co.za>
In-reply-to
Content
I checked this on 2.7.2a1, observed with jvisualvm, and I can reproduce what I understand is the OP's issue. "When the process has finished, and ODI finishes it's stuff, the delta is always exactly 32; it just keeps growing." So the OP's application is run repeatedly in the same JVM, and each time the threads remain alive (parked).

My test program is attached. It creates successive pools of 32 threads. A given pool behaves in the textbook way, but when the pool is dereferenced the JVM threads of the old one persist, so the JVM thread count shows a rising staircase. Other garbage collection is clearly going on happily. 

My difficulty is to know whether that is actually incorrect behaviour. Worker.run does not return, so the thread should not finish. This stackoverflow post, with almost identical code (run on CPython I assume), is helpful:
https://stackoverflow.com/questions/18610144/python-threads-are-not-being-garbage-collected

I'm taking off 2.5 as a target as we won't fix that as far as I know.
History
Date User Action Args
2018-03-17 10:55:47jeff.allensetmessageid: <1521284147.88.0.467229070634.issue1761@psf.upfronthosting.co.za>
2018-03-17 10:55:47jeff.allensetrecipients: + jeff.allen, fwierzbicki, amak, zyasoft, crankycoder, treaves
2018-03-17 10:55:47jeff.allenlinkissue1761 messages
2018-03-17 10:55:47jeff.allencreate