[jitsi-dev] Performance testing of Jigasi


#1

Dear list members,

I am doing a testing of latest releases of Jitsi and Jigasi. In my tests I am using SIPP to simulate calls and to join pre-existing rooms.
After completeing few calls, I am inspecting the Jigasi process, and every time I see running threads remaining, indefinetly, after the test has ended.

Remaining threads (excepts the ones that should be there) are the following:

Thread-268 [DAEMON] State: WAITING CPU usage on sample: 0ms
java.lang.Object.wait(long) Object.java (native)
java.lang.Object.wait() Object.java:502
org.jitsi.impl.neomedia.ProcessorUtility.waitForState(Processor, int) ProcessorUtility.java:150
org.jitsi.impl.neomedia.protocol.TranscodingDataSource.connect() TranscodingDataSource.java:123
org.jitsi.impl.neomedia.conference.AudioMixer.connect(DataSource, DataSource) AudioMixer.java:380
org.jitsi.impl.neomedia.device.AudioMixerMediaDevice$2.connect(DataSource, DataSource) AudioMixerMediaDevice.java:322
org.jitsi.impl.neomedia.conference.InDataSourceDesc$1.run() InDataSourceDesc.java:141

FMJ Thread: net.sf.fmj.media.ProcessEngine@282d03ba[ net.sf.fmj.media.ProcessEngine@282d03ba ] ( configureThread) [DAEMON] State: WAITING CPU usage on sample: 0ms
java.lang.Object.wait(long) Object.java (native)
java.lang.Object.wait() Object.java:502
net.sf.fmj.media.parser.RawPushBufferParser$FrameTrack.parse() RawPushBufferParser.java:482
net.sf.fmj.media.parser.RawPushBufferParser.getTracks() RawPushBufferParser.java:712
net.sf.fmj.media.BasicSourceModule.doRealize() BasicSourceModule.java:304
net.sf.fmj.media.PlaybackEngine.doConfigure1() PlaybackEngine.java:845
net.sf.fmj.media.ProcessEngine.doConfigure() ProcessEngine.java:1136
net.sf.fmj.media.ConfigureWorkThread.process() BasicController.java:1069
net.sf.fmj.media.StateTransitionWorkThread.run() BasicController.java:1224

FMJ Thread: SendEventQueue: com.sun.media.processor.unknown.Handler [DAEMON] State: WAITING CPU usage on sample: 0ms
java.lang.Object.wait(long) Object.java (native)
java.lang.Object.wait() Object.java:502
net.sf.fmj.media.util.ThreadedEventQueue.dispatchEvents() ThreadedEventQueue.java:40
net.sf.fmj.media.util.ThreadedEventQueue.run() ThreadedEventQueue.java:91

and different variation of such.

It seems that those are not being cleared after successful and graceful calls termination and a cooldown period.

I’ve trace jigasi and jitsi code as far as MediaAwareCallPeer, and I see that streams are being closed, for each peer, and moreover, the objects of Jigasi and jitis, related to calls, are cleared from memory (confirmed by memory snapshots review).

The question is if anyone knows what can be the reason of such. It must be a problem with my configuration/installation, since I don’t believe such fundamental thread leaks exists in a mature project. Please help.

Regards,
Dima Gutzeit.