XMPPConnection is growing

Smack Smack Dev
1

Hi

I writing a jabber-bot that monitors MUC-participants. When participant joined to chat his presence added to presenceMap in Roster.java, but never be removed from there. As a result I have a growing XMPPConnection of jabber-bot. The only place where the call presenceMap.remove is RosterPacketListener.processPacket(Packet packet) (not called when participant left chat). Please help to resolve this problem.

Thanks.

2 Likes
2

It seems that the only way to solve this problem, edit Roster.java as shown below (as in the older releases). Anyone can comment?

diff:

Index: Roster.java

===================================================================

— Roster.java (revision 13132)

+++ Roster.java (working copy)

@@ -746,9 +746,9 @@

// Otherwise, this is a normal offline presence.

else if (presenceMap.get(key) != null) {

Map<String, Presence> userPresences = presenceMap.get(key);

  •                // Store the offline presence, as it may include extra information

  •                // such as the user being on vacation.

  •                userPresences.put(StringUtils.parseResource(from), presence);

  •                userPresences.remove(StringUtils.parseResource(from));

  •                if(userPresences.isEmpty())

  •                    presenceMap.remove(key);

}

// If the user is in the roster, fire an event.

RosterEntry entry = entries.get(key);

3

This seems to be a quick and dirty fix, especially that the comment mentions the reason why we don’t remove the presence information from the presence map.

On the other hand, long running instances (like bots) could end up with an ever growing presence map. One solution could be an janitorial thread that cleans up old references from the map once every X hours or when it reaches a particular size.

4

We seems to be hitting the same problem in jicofo, our conference focus component, which is only using muc. I checked that this hasn’t been fixed even in new smack versions (we are still using an old one smack 3.2…). The simplest solution is to remove references for presence unavailable for which there is no RosterEntry.

Possible solution: When presence unavailable is received, remove any reference of the st… · jitsi/smack_3_2_2@ecbb546 · GitHub

5

Thanks Damian for the follow up. I’ve created SMACK-703 to track this.

After thinking again about it, I don’t even believe we would need such a janitorial thread as I mentioned above. Instead I think I would prefer the solution of using a bounded LRU cache like datastructure which holds the presences from entities not in the Roster, e.g. from a MUC. Compared to your solution of unconditionally not storing those presences.

6

I’ve uploaded Smack 4.2.0-alpha2-SNAPSHOT which includes https://github.com/igniterealtime/Smack/commit/f3817d6358d6fd7e488f04e02944643e0 eee9956

Now Smack should only cache a fixed amount of presences from entities not in the roster, which should fix the issue.