Timeouts seem to be a running theme but I don’t see how packetfilter and AD would interact.
Anyway I have a Openfire 3.5.2
mySQL 5.0.22
Centos 5.1
packetfilter 2.0.1
The plugin is installed and shows as a plugin. I can open the filter interface in the admin council but when I click create new filter it does nothing and eventually times out. I don’t see anything in any log file that might be pertinent. I also looked at the openfire DB table and the empty pfRules table is there.
It probably would have helped to mention that the packetFilter times out looking for the http://10.xxx.xxx.xxx:9090/plugins/packetfilter/rule-form.jsp
That file is definitely not in the packetfilter folder and no where on the server.
So am I the only one have problems with this plugin?
I would really like to use it keep admins from logging in.
Wade,
Could you try the 2.0.2 version here :
Also have you checked your caches? I helped another person that had an issue similar to this, turns out he had a bunch of groups and it was causing the group cache to thrash and slow things down to a crawl.
Cheers,
Nate
Thanks for the reply.
I upgraded to 2.0.2 since I first posted.
I have cleared all the cash categories in the past this time I cleared the two group cashes. Same result.
Is there an md5sum for the files?
Hi Nate,
Any further Ideas?
What I meant about the caches was that they could be too small. How many groups do you have? How many members on average per group.
I could probably tell what is happening if you gave me some thread dumps from when the app is hanging. On a Linux machine you can get a thread dump by doing a 'kill -3 ’ on a Windows system I think you can use JStack.
Cheers,
Nate
Kill -3 pid results in 0 output.
I have 8 shared groups, with a total of about 75 users out of an AD of >20k users
When you say 0 output does that mean that nothing was written to stdout or that the command didn’t run?
It is possible that it is your user cache that is the problem as well. If you check your cache settings page are any of the caches 80% or more full? Do any of them have a high percentage of misses?
There are no lines printed to StdOut.
Cash sizes,
group
90% .9 of 1mg 78.8% effective
roster
72.4% .18 of .25mg 89.6% effective
the next highest is vcard at
20% .1 of .5mg 87% effective
Cool, looks like the same problem. Here is what I sent the other guy having this problem that got him up and running :
The main problem seems to be that group cache gets full. Looking at the cache page in the admin console it will probably say that it is fullish but not completely (80-90%) possibly. So if you cache is 80% full and the next group to be inserted will take 25% of the cache then enough groups will be evicted from the cache until the new one fits. This causes a churn in the group cache, this is spiking your CPU.
The other issue is the lifetime of this cache, by default is only 15 minutes. This means you would be rebuilding your ldap cache every 15 minutes not good if you original cache takes 15 minutes to load in the first place.
Steps to fix :
In the admin console go to “Server”-“System Properties”.
Add a system property of with a name of cache.group.size and a value of -1. This means unlimited, it should be a huge memory hog. On my test system 5000 groups took about 23 megs.
Add another system property of cache.group.maxLifetime with a value of 86400000 which is 24 hours. I think eventually you would want to change this property so that the cache never expires. The downside being that no new groups would appear until you manually flush the cache.
Restart the server
Go to the packet filter page and attempt to create a new rule. This page will be very slow because it will start the filling of the group cache. If you go back to the “System”-“Caches” page you should be able to watch the group cache grow. Once it looks like it has leveled out, things should be running fine.
It worked after I hit about 1mg of group cash.