See SMACK-383, scheduled for a 4.0 release. I’d like to hear your input.
We are seeing the same memory leak problems described in the issue. Probably we will apply a similar patch to smack to use WeakReference in all those places storing connections in static fields.
Are there any plans of fixing those?
Are you interested in creating a PR to change that?
Any patch hat fixes a memory leak is more then welcome.
Did you perform a heap analysis? What is keeping a strong reference from the GC roots to the connection instance(es) you assume leaking?
And somewhere in the same xmppBosh connection which is weakReference in MUCManager there is a listener which is MUCManager.
The Manger.INSTANCES maps are WeakHashMaps. Therefore if those entries can not be collected then it is because there is still a strong reference to the key. Please see if there is such a strong reference, and if there is one, then check if it is caused by Smack or by code outside of Smack.
Just that there is no misunderstanding: What you provided so far does not back up your statement that
where I assume “the issue” to be SMACK-383.
But on the other hand I am of course not ruling out the possibility that SMACK-383 is not fixed/did reappear. But to determine that, we need to clearly identify the cause of the alleged memory leak you are seeing.
Yeah, I’m checking, trying to find why is this happening.
But I’m currently fighting with building smack. I haven’t build smack for few months (I had changed and computers) and there is new gradle and we are using the smack-4.2 branch with some changes and I cannot build it.
I’ve updated the build file with few changes from master but still for some reason it cannot find the source folders:
> Task :compileJava NO-SOURCE
file or directory '/Users/damencho/dev/Smack/src/main/java', not found
Skipping task ':compileJava' as it has no source files and no previous output files.
:compileJava (Thread[Execution worker for ':',5,main]) completed. Took 0.004 secs.
:processResources (Thread[Execution worker for ':',5,main]) started.
Do you have an idea?
Op, I just figured it out. Will update tomorrow with my debug findings …
I have verified that fix like the one SMACK-383 fixes the leak for us.
https://issues.igniterealtime.org/secure/attachment/11469/memory-leak.patch
But didn’t pointed out the real problem, just that there is a strong connection between key and value. I kept digging in and found one place in our code where the connection is not cleaned … Updating now with changes to verify that this is the problem. Sorry for the noise.
One side question, while looking at the new gradle build updates I saw osgi was removed, why? Is there a reason for removing it?
See [SMACK-343] - Ignite Realtime Jira
Please use a new topic for unrelated questions in the future. Thanks.