2.6.1 and up Shared Group Behavior Change

Openfire Openfire Dev
1

We have been using Wildfire and Jive Messenger since about this time last year. Up until recently we have seen few problems and its been an excellent piece of work.

I have tested many combinations of the following problem and a description of the problem(s) in its simplest form follows:

From scratch install of Wildfire (no previous directory, no database)

Once installed/configured, stop and restart server.

Create 3 users, monitor1, monitor2, monitored.

Create 2 groups, groupone, grouptwo. Disable sharing group in rosters.

monitor1 is a member of groupone, grouptwo.

monitor2 is a member of grouptwo.

Create 1 group, newgroup. Show group to members’’ rosters of these groups: groupone, grouptwo. monitored is a member of newgroup.

Using two different instances of XMPP clients, log in one as monitor1, the other as monitor2. The newgroup and monitored user appear in offline group of clients. Normally, at 2.6.0 nothing happens which is what I would expect. If we restart the server at this point and perform the logins again. monitor1 gets a presence message about monitor2. (I believe this is incorrect).

Using a third instance of an XMPP client, log in as monitored. Prior to 2.6.1 both monitor1 and monitor2 receive a presence message and show monitored as “available”. This is what is expected as well as desired. After 2.61 all the way to 19 May 2006 V3.0 alpha. This no longer works as expected. Noting happens at all on the monitor1 and monitor2 clients. If one of them is logged in/out. The monitored user appears “available” on the restarted client. Logging out the monitored user also has no effect. So it appears to be a loss of presence messages that previously had been transmitted by server.

So the question is bug or shared group behavior change by wildfire developers?

2

Hey sdooley,

Thanks much for the detailed description of the problem. I will try to reproduce it and get back to you with my results (hopefully a bug fix).

Regards,

– Gato

3

Thanks, for looking into the problem. I presume its a bug and not a behavioural change.

4

Any luck on this one? This prevents me from deploying 2.6.2 server over 2.6.0

5

I have been working on this one now. What I have found is it is a behavioral change. Supposedly its an optimization.

In Roster.java, I see the new code (snippet below)

In the constructor

String nickname = “”;

.

.

.

// Set nickname and store in memory only if subscription type is not FROM.

// Roster items with subscription type FROM that exist only because of shared

// groups will be recreated on demand in #getRosterItem(JID) and #isRosterItem()

// but will never be stored in memory nor in the database. This is an important

// optimization to reduce objects in memory and avoid loading users in memory

// to get their nicknames that will never be shown

if (item.getSubStatus() != RosterItem.SUB_FROM) {

item.setNickname(UserNameManager.getUserName(jid));

rosterItems.put(item.getJid().toBareJID(), item);

}

I suppose since this is an “important” change. It must remain. Problem is the users that were excluded from the Roster here don’t get picked back up in the broadcastPresence method of the same object. I will attempt a work around but any helpful hints would be appreciated.

Skip

6

I found what I consider to be a serious problem with the “optimization” besides it cause my software to no longer behave the way I would like.

Smack 2.2.1 and wildfire 3.0.0

In the initial discussion there were three users monitor1, monitor2 and monitored.

With the “optimized” roster implementation currently in, 2.6.1 - 3.0.0 Wildfire Presence is no longer being broadcast for monitored.

Well this includes BOTH Available and Unavailable types! Both are presence packets. I have tested not only with Smack and custom clients but with

Exodus, Spark, and Jeti all behave the same “BAD” way.

If monitored is up and running when monitor1 or monitor2 start then monitored will show up as available (since he did a roster request).

If monitored goes off-line monitor1 still shows monitored as available.

This is wrong, wrong , wrong! So the “optimization” fix broke more then the behaviour which used to be there.

skip

7

Hey Skip,

First off, sorry for missing this thread and thanks for refreshing me this issue. I’'m using Wildfire 3.0.0 and tried to reproduce this case. These are my results:

Using two different instances of XMPP clients, log in

one as monitor1, the other as monitor2. The newgroup

and monitored user appear in offline group of

clients.

That is correct and it is the expected behavior. These are the packets each client received:

RECV:

If we restart the server at this

point and perform the logins again. monitor1 gets a

presence message about monitor2. (I believe this is

incorrect).

Restarted server and things still look fine. These are the packets I got:

RECV:

Using a third instance of an XMPP client, log in as

monitored. Prior to 2.6.1 both monitor1 and monitor2

receive a presence message and show monitored as

“available”. This is what is expected as well as

desired. After 2.61 all the way to 19 May 2006 V3.0

alpha. This no longer works as expected. Noting

happens at all on the monitor1 and monitor2 clients.

If one of them is logged in/out. The monitored user

appears “available” on the restarted client. Logging

out the monitored user also has no effect. So it

appears to be a loss of presence messages that

previously had been transmitted by server.

So the question is bug or shared group behavior

change by wildfire developers?

Ok. Here we have an issue. When monitored logged in & logged out none of the other users received the available presence. However, when monintored changed his presence status to away, xa, free to chat, etc. those presences were sent to monitor1 and monitor2. I will file an issue and will try to fix this problem today or during the weekend.

Regards,

– Gato

8

My bad. Presences are never sent to monitor1 and monitor2. When connected many times from Exodus and you change you presence status then all your Exodus instances are modified.

Anyway, I just narrowed down the problem in the code.

– Gato

9

Hey guys,

JM-744 and JM-745 are fixed not. You can use the next nightly build (the Monday build) to test how things work now.

Regards,

– Gato

10

Well its better, but

There is always a but…

If a new user is added to the shared group while the server is up he is still

“Presence confused”. When the server is restarted he straightens out and plays correctly.

I saw some unusual behavior when I first started testing the Monday nightly. But then I couldn’'t reproduce it. I wiped everything out and started over and everything kept looking so good. Then I tripped over the repeatable problem.

With a fresh install and a Monday nightly build update.

Create 4 users, m1, m2, u1, u2.

Create a shared group s1 which is not displayed in rosters and has m1 and m2 as members.

Create a shared group u1 which is displayed in rosters of group s1 and has u1 as a member.

Create a shared group u2 which is displayed in rosters of group s1 and has u2 as a member.

Start clients using m1 and m2.

Start clients using u1 and u2.

m1 cannot see m2 and vice versa, good.

m1 and m2 see u1 and u2 available, good

stop clients u1 and u2, m1 and m2 see u1 and u2 go unavailable, good.

Create an m3 user, add m3 as a member of s1.

Start a client using m3.

Start clients u1 and u2.

clients m1 and m2 see u1 and u2. m3 does not.

stop client m3.

start client m3, m3 sees u1 and u2 as available.

stop u1 and u2. m1 and m2 see u1 and u2 as unavailable, m3 thinks they are still available.

stop everything including server, restart and retest.

all looks good now.

So you cannot dynamically add users to the s1 shared group,

that used to work in 2.6.0, doesn’t now, needs to

Skip

11

Hey Skip,

Thanks for another detailed bug report. I was able to reproduce it and studying now the best way to fix this problem. Will keep you updated.

Regards,

– Gato

12

Hey Skip,

The issue JM-750 is solved now. The bug fix will be available in the next nightly build (or you can just grab the code from SVN).

Let me know how it goes.

Thanks,

– Gato

13

Good job, looks like you nailed it. My tests show desired (correct) behavior now.

skip

14

Actually it doesn’'t seem that this issue hass been corrected at all.

I deployed a wildfire 3.0.0 server at my office. MySQL backend, no LDAP, and deployed on a Solaris 8 system.

with only a few users and mostly in the same group, we saw no issues. But as we ramped up the deployment and started populating more groups on the active server, users started reporting that entire groups and bunches of users were vanishing. They would reappear after a few logout-logins by the users reporting the behavior, or sometimes the problem would temporarily clear if we simply removed the user from a group and readded them, but this is destroying my credibility on this deployment.

Any way we can get a fix on this?

15

The actual fixes were in a nightly build of wildfire 3.0 and did not make it into Wildfire 3.0 release.

I see Wildfire 3.0.1 is now out and the Changelog indicates the fixes are in there but I have not tested it yet.

Skip