thanks, i’ll see if i can emulate something similar to this environment at home. or… does the xmpp.igniterealtime.org server have a group setup that we could add some test users to? i’m sure most accounts are inactive on it, but if we could add 200 users to a testing group then we may be able to replicate larger deployments in a dev environment… ?
PS: thanks for enabling the paging… this thread was getting out of control!
Thanks wroot. Here is my plan:
-I will revert all memory leak commits
-I will merge all fixes in one single commit without the ListRenderer change which I think that is causing the lock
It this way it will be easier to test and have feedback. Thanks again, I will post here when ready
Great. It would be nice to have those fixes for broadcast, missing offline icons and messages not showing as sent. Memory fixes can wait a little
I reverted all mem leaks commits only (6 commits) and I kept other patches (I did not keep the offline ball icon fix because I want to have the contact list untouched). I checked bamboo and there is a new build available: 625 - please let me know if you still experience spark lock with build 625
I will make now one single commit where I remove the contact list render mem leak fix (which turned to be a jdk 6 mem leak so probably in reality my code had no effect) and I merged the following obvious mem leak fixes:
-replace java.util.Timer with javax.swing.Timer for UI handling and keep the delay values
-group chat accumulation fixes (one single chat room listnener for all opened group chat rooms and use string jid in hashMap for transcript history instead of entire room)
Build 626 is now available. it contains all mem leak fixes in one singe commit, and without the list renderer change
Please let me know if build 625 is OK and if there are issues with build 626. Thank you so much for your help!
Any news on builds 625, 626, are the locking issues still reproducible?..thanks
I have installed 625 on my an my colleague’s PCs. Testing for 2 days now. So far no problems. But my PC rarely goes to sleep.
Thanks. Please let me know when you get a chance to test 626 build and if you see any difference. I removed list renderer pane change and all other mem leak fixes are in one single commit - build 626. Thanks again
Well, i have installed 626 today, but it probably would take some time to fully test it.
Daily update. After a whole day so far no freezes on 626. My PC went into sleep once, but everything was fine after waking it up, though i didn’t had any open chats at that moment.
Thanks wroot. I think I found a even better approach without the use of any additional timer (javax.swing.timer, or any other type of timers)
I searched again Spark code and I found two utility classes that are built for these purposes:
TaskEngine.java and SwingTimerTask.java. They combine the use of java Executors and thread pool technique and Swing tasks. This looks to me the best solution and I am surprised why wasn’t used in ContactList presence notifications. I am testing this solution now.
I commited the TaskEngine solution. We do not need additional timers as we already have api support in spark for such tasks. build 627 is available and it looks good to me
Installed 627 now. 626 was ok, though it was only a few days of usage.
A problem that may be worth mentioning here because you have been working on chat rooms is as follows.
When trying to enter a password protected chat room, and enter the wrong password you get the message that “The password did not match the rooms password”. Then by selecting the room again you enter the correct password to successfully enter the chat room, all good so far.
When the connection to the Openfire server goes offline, for example because the client computer is connecting over a personal VPN connection, when the Openfire server becomes available because the VPN connection is restored Spark will reconnect, Spark will then report “The password did not match the rooms password”, i.e. it is still trying to use the initial incorrectly entered password.
When the correct password is used to join the chat room, the participants visible user name is changed from for example CaraselM to CaraselM4.
Another unexpected effect is that when for example the renamed user CaraselM4 types a new comment to the chat room the chat room thread shows first a comment from CaraselM4 and then second the same comment again this time from CaraselM.
The symptoms described above happen in earlier builds and still happen in build 626/627.
Is this a problem recently introduced or it was since long time ago?
Changes I did for group chat room does not touch this area, so likely this is an issue that require a new ticket opened
This problem has existing for some long time. Getting the password wrong first time appears to be a reliable way to reproduce the problem with the chat room participant name being appended with the number 4 and the double entry comment side effect. This assumes that the connection to the Openfire server is lost temporarily as described earlier.
I put back the cell renderer panel mem leak fix. JDK 7 did not seem to remove the leak without this fix, so I retested and put it back. build 630 is available. If you have time please have a look on build 630 and let me know if you see any locks. If there will be problems, I will revert the commit. Thank you so much for your help!
I spoke too fast Build 630 still has the locking issue. I know now from where it is. I was setting the presence in the new renderer instead of just setting the presence icon. setPresence triggers a presence changed event once again. I will revert this commit and make it right. sorry… please don’t waste your time with build 630…thanks
Build 632 is now available with the proper cell renderer pane memory leak fix. Thanks!
Mircea, will try 632 build next week. Though we will have only 2 shortened working days, so not much testing
AjsAjs, i have filed your issue as SPARK-1561.