[jitsi-dev] Resource Leak - Excessive number of Threads


#1

Hey

The changes related to the KeepAlive stuff (I think) caused that the Jingle
Nodes Discovery leaks resources:
- JabberProvider registers
- Starts the node discovery
- which starts/creates a SmackServiceNode (startJingleNodesDiscovery, Line
2319)
- which creates a ThreadPool (<--- this is the leaked thread,
SmackServiceNode Line 33)

The SmackServiceNode would stop the ThreadPool after the smack connection is
closed (SmackServiceNode Line 104), but it never gets that event. Because it
never registers (SmackServiceNode.connect, Line 61) as connect is never
called.

Now after unregistering our JabberProvider, the jingleNodesServiceNode is
kept, and a new registration simply creates a new SmackServiceNode,
regardless of whether there is already one.
-> Leak!

To reproduce it, just create an XMPP account and
register/unregister/register several times and watch how threads named
"pool-X-thread-1" appear.

Why do I care at all? Because Jitsi recently crashed after a few days,
showing 650 (sic!) threads in the task manager. I don't know enough about
all the XMPP/Jingle stuff to fix it myself, so... Damian? :slight_smile:

Cu,
Ingo


#2

Hi Ingo,

I know there is some problem with jabber, last week I tried to fix a
problem with keep alive and jabber provider keep reconnecting.
Thank you for sharing your investigations, I will look at these
problems later today and will keep you informed where things are going
on.
There is one more problem with jabber provider which currently I
cannot reliable reproduce, some times jabber provider goes through
registered state two times, one after another, without going through
unregistered/connection failed... which was one of the problems with
keep alive stuff.

Thanks
damencho

···

On Wed, Feb 1, 2012 at 12:28 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hey

The changes related to the KeepAlive stuff (I think) caused that the Jingle
Nodes Discovery leaks resources:
- JabberProvider registers
- Starts the node discovery
- which starts/creates a SmackServiceNode (startJingleNodesDiscovery, Line
2319)
- which creates a ThreadPool (<--- this is the leaked thread,
SmackServiceNode Line 33)

The SmackServiceNode would stop the ThreadPool after the smack connection is
closed (SmackServiceNode Line 104), but it never gets that event. Because it
never registers (SmackServiceNode.connect, Line 61) as connect is never
called.

Now after unregistering our JabberProvider, the jingleNodesServiceNode is
kept, and a new registration simply creates a new SmackServiceNode,
regardless of whether there is already one.
-> Leak!

To reproduce it, just create an XMPP account and
register/unregister/register several times and watch how threads named
"pool-X-thread-1" appear.

Why do I care at all? Because Jitsi recently crashed after a few days,
showing 650 (sic!) threads in the task manager. I don't know enough about
all the XMPP/Jingle stuff to fix it myself, so... Damian? :slight_smile:

Cu,
Ingo


#3

Hey Ingo,

I think its fixed now. Thanks for the report. Looking at the problem I
found a leak. Where old XMPPConnections stay in memory after
reconnect. The problem was in smackx.ChatStateManager and its use of
WeakHashMap.

Thanks
damencho

···

On Wed, Feb 1, 2012 at 8:59 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hi Ingo,

I know there is some problem with jabber, last week I tried to fix a
problem with keep alive and jabber provider keep reconnecting.
Thank you for sharing your investigations, I will look at these
problems later today and will keep you informed where things are going
on.
There is one more problem with jabber provider which currently I
cannot reliable reproduce, some times jabber provider goes through
registered state two times, one after another, without going through
unregistered/connection failed... which was one of the problems with
keep alive stuff.

Thanks
damencho

On Wed, Feb 1, 2012 at 12:28 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hey

The changes related to the KeepAlive stuff (I think) caused that the Jingle
Nodes Discovery leaks resources:
- JabberProvider registers
- Starts the node discovery
- which starts/creates a SmackServiceNode (startJingleNodesDiscovery, Line
2319)
- which creates a ThreadPool (<--- this is the leaked thread,
SmackServiceNode Line 33)

The SmackServiceNode would stop the ThreadPool after the smack connection is
closed (SmackServiceNode Line 104), but it never gets that event. Because it
never registers (SmackServiceNode.connect, Line 61) as connect is never
called.

Now after unregistering our JabberProvider, the jingleNodesServiceNode is
kept, and a new registration simply creates a new SmackServiceNode,
regardless of whether there is already one.
-> Leak!

To reproduce it, just create an XMPP account and
register/unregister/register several times and watch how threads named
"pool-X-thread-1" appear.

Why do I care at all? Because Jitsi recently crashed after a few days,
showing 650 (sic!) threads in the task manager. I don't know enough about
all the XMPP/Jingle stuff to fix it myself, so... Damian? :slight_smile:

Cu,
Ingo


#4

Hey

Okay, great, thanks!

cu,
Ingo

From: damencho@damencho.com [mailto:damencho@damencho.com] On Behalf Of
Damian Minkov
Sent: Mittwoch, 1. Februar 2012 20:43
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Resource Leak - Excessive number of Threads

Hey Ingo,

I think its fixed now. Thanks for the report. Looking at the problem I
found a leak. Where old XMPPConnections stay in memory after
reconnect. The problem was in smackx.ChatStateManager and its use of
WeakHashMap.

Thanks
damencho

> Hi Ingo,
>
> I know there is some problem with jabber, last week I tried to fix a
> problem with keep alive and jabber provider keep reconnecting.
> Thank you for sharing your investigations, I will look at these
> problems later today and will keep you informed where things are going
> on.
> There is one more problem with jabber provider which currently I
> cannot reliable reproduce, some times jabber provider goes through
> registered state two times, one after another, without going through
> unregistered/connection failed... which was one of the problems with
> keep alive stuff.
>
> Thanks
> damencho
>
>> Hey
>>
>> The changes related to the KeepAlive stuff (I think) caused that the
Jingle
>> Nodes Discovery leaks resources:
>> - JabberProvider registers
>> - Starts the node discovery
>> - which starts/creates a SmackServiceNode (startJingleNodesDiscovery,

Line

>> 2319)
>> - which creates a ThreadPool (<--- this is the leaked thread,
>> SmackServiceNode Line 33)
>>
>> The SmackServiceNode would stop the ThreadPool after the smack

connection

is
>> closed (SmackServiceNode Line 104), but it never gets that event.

Because

it
>> never registers (SmackServiceNode.connect, Line 61) as connect is never
>> called.
>>
>> Now after unregistering our JabberProvider, the jingleNodesServiceNode

is

>> kept, and a new registration simply creates a new SmackServiceNode,
>> regardless of whether there is already one.
>> -> Leak!
>>
>> To reproduce it, just create an XMPP account and
>> register/unregister/register several times and watch how threads named
>> "pool-X-thread-1" appear.
>>
>> Why do I care at all? Because Jitsi recently crashed after a few days,
>> showing 650 (sic!) threads in the task manager. I don't know enough

about

···

-----Original Message-----
On Wed, Feb 1, 2012 at 8:59 AM, Damian Minkov <damencho@jitsi.org> wrote:
> On Wed, Feb 1, 2012 at 12:28 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:
>> all the XMPP/Jingle stuff to fix it myself, so... Damian? :slight_smile:
>>
>> Cu,
>> Ingo
>>