Memory leak in MultiUserChat

Smack Smack Dev
1

Hello, please check MultiUserChat.enter(…) in 4.1.9 version.

Line number 307:

307#messageCollector = connection.createPacketCollector(fromRoomGroupchatFilter);

It creates PacketCollector which will store in AbstractXMPPConnection.collectors queue. In condition if connection is not connected and code will be calling MUC.join(…) in loop - the queue will grow up, cause PacketCollector created at line 307 will not be cleaned if NotConnectedException occures. Each call add 1 dead object to this queue.

Is it bug, or should I make some workarounds?

ml2.png1872×811 188 KB

ml1.png1829×977 221 KB

2

Thanks for reporting. I’ve created [SMACK-745] Memory leak in MultiUserChat - IgniteRealtime JIRA

Should be fixed in 4.2.0-rc3-SNAPSHOT. Please report back if it fixes the issue for you.

3

Thanks, i’ll check it this week.

Also, can you have a look at org.jivesoftware.smack.sasl.SASLMechanism.compareTo(…)

public final int compareTo(SASLMechanism other) {

return getPriority() - other.getPriority();
}

Here is comparing priority of SASLMechanism, and this is an issue, cause comparing two int values using substraction is bad. As for me i’ve registered two custom SASLMechanisms(i changed priority for test issues), overided getPriority(), first returns -1000, second returns Integer.MAX_VALUE. And have an issue when them was sorted (-1_000 - 2_147_483_647 = positive number in int32). So mechanism with lower priority became the highest one.

For example use please Integer.compare - in java lang .

public static int compare(int x, int y) {

return (x < y) ? -1 : ((x == y) ? 0 : 1);
}

4

I meant mechanism with higher priority became the lowest one.*

5

Thanks, committed Fix SASLMechanism.compareTo(SASLMechanism) · Flowdalic/Smack@ffe9397 · GitHub and uploaded a new snapshot. Please test and report back if it fixes the issue.