Deleting Server Side Group

Openfire Openfire Support
1

Using Jive Messenger 2.1.2.

Authenticating against LDAP (Novell eDirectory)

Using a custom ldap search string

Using MSDE as a data store

Using Gush as a desktop client

Everything seems to be working great, except for one little problem. I am not able to delete a server side group without sending our ldap server into a frenzy. I have set up a couple of groups that include ldap usernames as members. When I try to delete the group, the utilization on our Novell server jumps up and I finally have to kill the Jive service. In the browser, I just see “host contacted waiting for reply” until I kill the Jive server. Once I stop the Jive service, the Novell server utilization drops back down to its normal range.

I did some searching of the forums, but couldn’'t find anything about deleting groups. Where am I going wrong here?

Thanks for your help,

Ben H.

2

Completely removed as the suggestion wasn’'t even close to the actual problem experienced.

“Read the entire thing before posting next time!”

Message was edited by:

toetag

3

I am also seeing this problem when I try to add an ldap user to a server side group. The browser just waits with a “host contacted” message, the utilization on the Novell server jumps up to 25-30%, and I finally have to kill the Jive service on the Windows box. When I kill the service, the Novell utilization levels back out at its normal 1-5% utilization.

Ldap authentication is working perfectly. I can go to the User Summary screen and see a list of the user objects returned by my custom ldap search string. So, Ldap itself is not failing. It must be something to do with the groups functionality.

Anybody else using this same setup?

4

can you post any logging that might have taken place during the high CPU usage?

And feel free to ignore my previous comment, it had nada to do with the issue you are describing. The schools i attended, stayed away from reading as part of the edumikation system.

5

Hey Ben,

Why is it that you have to kill the server? Is it that the process never ends or is it taking too long? In any case, I would like to reduce the consumption of CPU so I will need more information.

I will need to know the group configuration that you are using. For instance, which group configuration are you using when adding a new user to the group? Is the group configured to be shown in all the users’’ rosters? Is it possible to “sniff” the requests made to the LDAP server so we can figure out which one is consuming so much CPU? My guess is that you are using a public group so all the ldap users are being retrieved again which may be an expensive operation. FYI, an optimization that we were thinking of doing was to replace getting all the users and instead use the connected users.

Regards,

– Gato

6

Gato,

I have spent some time this morning trying to gather more information. Previous to your post, it hadn’'t occured to me to check the cpu utilization on the windows box running the Jive server. I was maily concerned about the cpu on our Netware server. I will add that, today, I have been able to add users to newly created groups without any problems.

This morning, for the purpose of testing, I created a new group called Test. This group is set to show in all users’’ rosters. I added an ldap user to this group. This particular user has never logged into the jive server to do instant messaging. The group sets up and is displayed correctly in users’’ rosters.

When I try to delete the group using the admin console, the cpu utilization on the jive server / windows box jumps to and stays around 50-55%. The cpu utilization on the ldap / novell server jumps up to 15-20%. Both servers continue with this utilization until I stop the jive messenger service.

In your post, you asked if the procedure is just taking too long to complete, or if it never stops. In reality, I guess I don’‘t know if it would ever stop. In my testing this morning, I gave it about four minutes before I finally killed the service. In my mind, if it hasn’‘t stopped by then, it’'s not going to until something catastrophic happens.

I turned on debug output on the jive server while I attempted to delete the group. The output is this:

.03.17 10:35:56 Creating a DirContext in LdapManager.getContext()…

2005.03.17 10:35:56 Created hashtable with context values, attempting to create context…

2005.03.17 10:35:56 … context created successfully, returning.

2005.03.17 10:40:43 Creating a DirContext in LdapManager.getContext()…

2005.03.17 10:40:43 Created hashtable with context values, attempting to create context…

2005.03.17 10:40:43 … context created successfully, returning.

What you see above just repeats from 10:35:56 to 10:40:43. I can see in the info.log that at 10:40:43 the jive server halted (when I killed the service). One thing I noted was that I didn’'t hit the delete button in the browser until 10:36:25 (jive server time). However, there seems to be no difference in the debug output beginning at that time.

I don’'t know of a way to actually see the queries that are being made against the ldap server, short of packet sniffing. Anything else you can suggest before having to go that far?

7

It sounds like at least one operation in the shared groups or LDAP code is very unoptimized. My guess is that it’‘s trying to load each user object individually and is not hitting those users in cache. That would be extremely expensive in a large LDAP directory. We’‘ll need to dig into the code to see what’'s going on.

-Matt