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()
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.
The group chat memory leak fix has a side effect (history messages are duplicated) - working on a fix
fixed with: Committed r13818
-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
Well, it is 2 months now and everything looks fine, so i will close this ticket for now.