powered by Jive Software

2.5.0 LDAP Bug

Ok, so we deployed Wildfire 2.5.0 with LDAP shared groups. Initially we had 40 some users all in the same group. I set “Show group in member’'s rosters” and all was working great. Then today, I needed to add a user who was not a member of this group, but wanted that user to see the other group. So I went in and changed the setting to “Show group in all user’'s rosters.” 2 things happened:

  1. The web page never returned (waited several minutes). Reloading the page showed the new setting however.

  2. A (random?) member of the shared group seems to have lost membership in the group. The user still shows up in the group list on the page, but not on anyone’'s roster.

Obviously this is a very specific thing and hard to reproduce, but has anyone else experienced this? Any debugging tips to figure out whats going on?

Ok, something odd is going on… as time goes on more and more users are getting “unsubscribed”

Hi Jay,

do the Wifi log files look ok?


yes, nothing is showing up in the logs all seems normal from that perspective.

Looking at the database (using Postgres) and from what Gato mentioned to me, it looks like Wildfire is unsubscribing everyone, then subscribing them back. This seems horribly innefficent… and for a userbase of 42 users, this is taking an extrodanarily long time.

In the database, the jiveroster table should hold all roster entries, right? So with a simple shared roster where everyone is on everyone elses roster, the database should have 1764 (4242) entries, right? No, wait… it would be 1722 (4142) because most people wont be on their own roster (though some will, so thats not a hard number). We had 400 entries in that table when I started this email, and are up to 512 now. As I type, I notice that number is growing very, very fast; it had remained fairly stable around 400 for some time.

Can one of the developers clue me in as to what sort of logic is applied here? Maybe we can make this a bit more efficent?

Though we dont plan on making changes like this often, when we do its a major problem to have everyone with no contacts in their roster for an hour or so.

Hi Jay,

this is evil. I tried it with the embedded database, 2000 queries like these ones for 24 users:



INSERT INTO JIVEROSTER VALUES(260,’’****1’’,’‘test5@jabber.org’’,2,-1,-1,’‘test5’’)






/C6/INSERT INTO JIVEROSTER VALUES(261,’‘test5’’,’’*****1@jabber.org’’,1,-1,2,’’*****1’’)


INSERT INTO JIVEROSTER VALUES(260,’’****1’’,’‘test5@jabber.org’’,0,-1,-1,’‘test5’’)


I was using the embedded database so I don’‘t have a network latency which may turn out to be really bad. So maybe there’'s still a thread running in Wifi, which is of course non-transacted so you better keep the system running until it has finished its job.


Ouch. No transactions either? Maybe thats just for the embedded database (I hope so anyway).

Its still running for me… leveled off again at around 600 entries.

For hope I`d give my everything.

Oh how I wish for soothing rain.

Oh how I wish to dream again.


Wifi is open source so you could take a look at the code and build up your own mind about transactions.


I’'m getting something similar time to time (last with 2.4.4 version). It happens when i try to delete a group, users, or changing sharing options. Users are loosing their own group in rosters. But i cant wait. Once i have recreated DB. Last time restarting of server fixed that.

it2000: My understanding of java and databases is too limited at this point to know if/how/what transactions work in Java. But, I am learning more about Java every day at this point…

Wildfire got to be too unusable for us, I stopped the server, started it back up again, and now everyone’'s roster looks correct. But- the database table ‘‘jiveroster’’ seems incomplete. For example, my roster only shows 5 users in the table, but my roster when logged in is complete with 41 users.

So this beggs the question: what is Wildfire doing in the database? It apparently dosnt need these entries, but was very consumed with updating them before the restart.

Upgraded to new version- dosnt seem to be an issue at present.