Multiple memory leaks

Description

I have been monitoring spark for few weeks now and I identified three places with memory leak issues

1. GroupChatParticipantList that implements ChatRoomListener.
The problem here is that if you have 5 group chat rooms opened you will have 5 listener instances, and when someone joins one of the rooms, all 5 listeners will be notified. The resolution here is to keep only one ChatRoomListener instance. ChatRoomListener methods have groupchat instance as parameter in all methods, so you know what room will be notified
2. JPanelRenderer - used to render ContactList items. For every offline-online message you will get contact item added/removed from online to ofline. One instance is kept in the renderer and accumulates over time. For example I run spark for a week and I got 140 MB memory accumulated in ~2000 instances of ContactItem. The resolution here is to return always one rendered instance each time painted according with ContactItem status (online, offline etc)
3. In ContactList.java the changeOfflineToOnline method creates a Timer every time - in 24 hours this causes a thread lock reported in threaddump file - solution here is to replace Timer with a Swing task -SwingUtilities.invokeLater(new Runnable()

Environment

None

Activity

Show:
wroot
November 27, 2013, 10:03 AM

Spark is bundled with java 7 in bamboo, so i think it should also be build with jdk 7, though i'm not sure. But spark is still hooking into java 6 if it founds such installed on the system, even if it already has jre folder bundled.

Mircea Carasel
November 28, 2013, 6:55 PM

The group chat memory leak fix has a side effect (history messages are duplicated) - working on a fix

Mircea Carasel
November 28, 2013, 9:27 PM

fixed with: Committed r13818

Mircea Carasel
December 2, 2013, 11:30 AM

Committed r13821

-use javax.swing.Timer instead of java.util.Timer
-do not sleep inside invokeLater task (causes UI to lock)
-javax.swing.Timer has the advantage to execute tasks inside swing UI thread
and is recommended to use in UI instead of java.util.Timer.
javax.swing.Timer does not need a invokeLater call and can execute tasks given a specific delay

wroot
February 7, 2014, 10:21 AM

Well, it is 2 months now and everything looks fine, so i will close this ticket for now.

Fixed

Assignee

Mircea Carasel

Reporter

Mircea Carasel

Labels

None

Expected Effort

None

Fix versions

Affects versions

Priority

Major
Configure