Group Subscription Messages Not Received After Client Logged In for

Openfire Openfire Dev
1

Group Subscription Messages Not Received After Client Logged In for Extended Period

An XMPP client is being used to monitor presence of new users. The client is logged in as a user in a group that is shared by new groups. Normally, a new user is created, added to a new group, the group is shared with the client group and the new user is logged in. The client then displays the new group and user?s presence. After running for about 6-7 hours the newly created users/groups are not displayed on the client. The user?s presence information is received, but the client does not receive a message with the group subscription information. The Wildfire logs do not show any errors or evidence of trying to send the group subscription information. This can be seen using Exodus XMMP client with the auto away features disabled. This problem does not occur with the Spark client. As a work around to this, our client software now sends a presence available message every 15 minutes and receives all expected messages.

2

Yes, this is a tough one! Because of the time needed to establish the problem. Anyone who is possibly using an XMPP client w/Wildfire on a 24/7 basis should be concerned with this type of a problem. We have tested this a number of different ways. Trying to accelerate the symptons by increasing keep alive periods to advancing the system clock (which smack didn’'t like). We found no way other then wait 5-6 hours to make problem appear. Even though we have established a work aroudn for this, it would be nice to get a real fix.

3

Hey,

A small question, you established that this doesn’'t occur with Spark, are you seeing it with other clients besides exodus? If not how did you establish that it was not an Exodus issue?

Thanks,

Alex

4

The problem was analyzed with 4 different XMPP clients.

Spark, Exodus, Jeti, and our custom XMPP client which is based on JETI.

The problem occurred with all the clients except Spark.

Spark, for whatever reason, never displays a newly added shared group followed by a suer in the group logging in. So it never behaves the same as the others anyway so as far as this problem goes it wasn’'t useful for the test anyway.

In essence, the problem is

Create GROUP A, USER A, Login with a client.

Create GROUP B (members visible by A), USER B, Login with a client

(user is displayed on A) B can send messages to A, life is good.

Wait 6 hours

Create GROUP C (members visible by A), USER C, Login with a client.

User is NOT displayed on A, although C can send messages to A.

Makes it difficult for a to originate a message to C.

Skip

5

The one thing I can think of that perhaps could be causing the trouble after 6 hours is the caches. You may try lowering the time things are held in the cache and then seeing if you can reproduce this issue more rapidly, then we will also know what is causing the issue.

Alex

6

I think your theory is good. I see no easy way to adjust this cache time via console. No property seems to exist that I can associate with cache time.

Perhaps a code change and rebuild server?

Do you know where to change this?

skip

7

While there currently isn’'t a page in the admin console for it all the cache times can be configured through jiveProperties. The pattern is “cache.propertiesName.expirationTime”, so, we then need to look to see the cache names. The group caches by default only last 15 mins, so I searched for any that set six hours and we have one suspect, the Roster cache whose propertyName is “Roster”. Try lowering the time and see if you can make your issue occur more rapidly.

Thanks,

Alex

8

Well, it was a good theory but had no effect. We tried 600 ms, 10 minutes. There was no effect. I tried to recompile server but got some errors near the end of the build. Was going to try and change the default value but no luck.

skip