I can say that Gato’‘s question 2 is not that related to LDAP. Shared contacts and rosters determine how groups of users see each other, and are configured within Wildfire (probably through Admin Console), so LDAP simply does not have anything to do with such a feature (by default). In other words, if you haven’'t done anything to the groups after they are loaded, that should not be a problem.
Thanks Patrick, that helps.
My setup is bare minimum to get wildfire running so I wouldn’'t have anything special setup for groupings.
When this query for all groups finally finishes, then
the clients pop up windows to confirm the request to
add to buddy list.
Hey Joel:
Did you mean to say that LDAP is being queried for groups then if you aren’'t using groups? Did you mean something else? We are trying to understand your setup.
Thanks,
Alex
Did some checking, there is nothing special setup regarding groups, everything there is out of the box vanilla setup as viewed in the admin pages. Also to see wildfire.xml you can see my first posting, that is all vanilla too except for ldap and postgres setup. So assuming that you are asking about group settings that would show up either in conf/wildfire.xml or on the users/groups tab of the admin console I do not have anything except defaults.
Second, we got suspicious that maybe since we had created users in the admin console and logged in that way a few times before changing to ldap, that perhaps it had confused things. So we dropped the postgresql database and recreated it using the wildfire scripts in resources subdir.
So, on the first user to login I see ldap queries walking all 2000 user entries.
I think it is building a list of all possible users and groups at this point.
Then I have a second person login, there are no additional ldap queries.
Then one of those 2 requests to be on the other persons buddy list, this causes another large set of ldap queries effective hanging wildfire server for another 3 minutes. So I think Dombiac was wanting to check and see why it couldn’'t be using cached information at this point instead of redoing all of these ldap queries for users and groups.
So the wildfire behaviour is the same after dropping the users and starting fresh.
Let me know if I have answered your questions about our setup of groups. If not, please provide more details on where I would look to determine our settings.
Thanks,
Joel Schaubert
Message was edited by: bikeracer4700
Hey Joel:
According to your setup you are specifying that you would like to use ldap groups, if you don’'t want to use ldap shared groups you should remove this property from the wildfire.xml:
/code
What that property does is tell Wildfire to use groups specified in LDAP… it searches for all groups by doing a search (member=*). That is likely why you see the queires related to groups. Lets try and get users and auth working first so remove that line for now.
Alex
Hey guys,
Joel, the nightly build version includes some optimizations related to the issues reported by you. Reading your last post makes me think that there might be more things that we may improve for the next release. Anyway, I would recommend using the next[/b] nightly build and try again. To update current installation with a nightly build version you will have to:
-
Stop your server and make a back up of the database, the lib/wildfire.jar file, the plugins/admin folder, resources/database folder and config/wildfire.xml file.
-
Download nightly build version and install it in a new folder
-
Start nightly build version to unpack packed files. There is no need to log into the admin console and configure new install. Stop the server once lib files were unpacked.
-
Copy the lib/wildfire.jar file, the plugins/admin folder and resources/database folder over your existing installation.
-
Start the server again.
Could you provide us information about the average number of users that you have in the users’’ rosters? The only LDAP queries to gather user information should be for those users that are present in the roster. Also when not using posixMode more LDAP queries are performed.
Note: Roster is an alias for contacts list. In other words, roster is the classic window that you have in your IM client with the list of contacts.
Let us know how it goes.
Thanks,
– Gato
Message was edited by: dombiak_gaston
Thanks Gato.
Tomorrow morning I will grab the build and retest the scenarios to see if wildfire is more willing to use cached information.
As far as roster size, we are currently testing wildfire to see if we can change to it for our corporate IM. So right now we only have 5 people testing it, max roster size would be 4.
The only thing especially interesting about my case right now is the large size of the active directory and the freeze’'s I can see when wildfire walks the whole directory.
From Alex’'s post I did try removing the section that kicks in shared groups and retested.
/code
So what I found is that with this section removed, wildfire never walks all of the groups and users over in the active directory.
I’'m going to put this back in for the testing tomorrow with the nightly build.
Joel Schaubert
-
downloaded 3/23 build
-
unpacked
-
thedude bin # ./wildfire.sh
…
Wildfire 2.6.0 Beta
Admin console listening at:
Server halted
- copy files to regular install
thedude wildfire_2006-03-23 # cp lib/wildfire.jar /opt/wildfire/lib/
thedude wildfire_2006-03-23 # cp -r plugins/admin/* /opt/wildfire/plugins/admin
thedude wildfire_2006-03-23 # cp -r resources/database/* /opt/wildfire/resources/database
- restart
/etc/init.d/wildfire start
Things are not working so good.
a) admin console won’'t come up
2006.03.23 11:35:46 org.jivesoftware.wildfire.container.PluginManager$PluginMonitor.run(PluginManage r.java:646) Error unloading plugin admin.orig. Will attempt again momentarily.
…later…
2006.03.23 11:36:16 org.jivesoftware.wildfire.container.AdminConsolePlugin.initializePlugin(AdminCon solePlugin.java:183) Trouble initializing admin console
org.mortbay.util.MultiException[java.net.BindException: Address already in use]
at org.mortbay.http.HttpServer.doStart(HttpServer.java:673)
/code
b) None of the ldap lookups for users seem to be returning hits. Those for groups do seem to be working.
2006.03.23 11:41:26 User DN based on username ‘‘cn=#inst - settlements (tokyo),ou=ou_mailing lists,ou=ou_groups,dc=corp,dc=grp,dc=com’’ not found.
2006.03.23 11:41:26 Exception thrown when searching for userDN based on username ‘‘cn=#inst - settlements (tokyo),ou=ou_mailing lists,ou=ou_groups,dc=corp,dc=grp,dc=com’’
org.jivesoftware.wildfire.user.UserNotFoundException: Username cn=#inst - settlements (tokyo),ou=ou_mailing lists,ou=ou_groups,dc=corp,dc=grp,dc=com not found
/code
So I wasn’'t able to do any testing to see if there is better cache hitting on the cases of adding a buddy, and on changing from overnight idle back to active.
In other news while stiill on 2.5.1 I noticed a limitation in the admin console.
After our first user hit when the big ldap query is done runing, you can use the admin console to go to users and groups.
But I think there must be some wildfire limitation hard coded somewhere to stop at 5000 users. When I go to the last user I am only at the letter “m”, and so I expect I am only able to display about half the true users. Is this limitation just in the display code?
Also it would be nice if you could pick more than 100 users per page when viewing users in the admin console. It’'s easier to use the scroll on the browser than it is to click though 500+ pages of users.
Let me know if I should adjust something and then give another try to testing one of the latest builds.
I should mention that I also tried to take the 3/23 SOURCE release and I told gentoo that it was 2.5.2 (renamed the tarball etc). So then I tried a full install of this as 2.5.2 This included blowing away my database and re-seeding just in case any schema had changed. But I got the same results where admin console would not work and the ldap queries seemed to be working for groups but not for users. (gentoo makes it extremely easy to totally blow away one version of a product and try another one which is why I tried it with the nightly build source).
Joel Schaubert
Hey Joel,
Sorry to hear that you had some trouble using the nightly build version. Today we checked in a couple of very important performance improvements (JM-607 and JM-608) so you will have to upgrade to the next nightly build.
To make the upgrade and follow up easier feel free to contact me by IM. You can get my IM address from my profile.
Thanks,
– Gato