Item9838: WikiGroups runs into "premature end" error if you have many groups
Priority: Urgent
Current State: Closed
Released In: 1.1.1
Target Release: patch
Applies To: Engine
Component:
Branches:
Reported by
GuentherFischer via mailing list.
I copied most parts of my old Main-Web like
WikUsers, *Group
SitePreferences etc. and have now a big problem with
WikiGroups. The listing of the Groups goes to Error: Premature end of
script headers: view
I nearly have 120 Grroups.
Then I delete all my own Groups and add only Groups step by step and
test the WikiGroups-page. It works with 3...10 Groups
but gets slower and slower till the error ocours ...
--
GuentherFischer - 18 Oct 2010
Can you please c'n'p the whole error message (from apaches errorlog) and tell me your LoginManager, PasswordManager and UserMapper settings?
--
OliverKrueger - 18 Oct 2010
Hi Oliver,
[Mon Oct 18 11:20:14 2010] [error] [client 134.109.201.15] Premature end of script headers: view, referer:
https://twiki-test.hrz.tu-chemnitz.de/bin/view/Main/WebHome
$Foswiki::cfg{LoginManager} = 'Foswiki::LoginManager::TemplateLogin';
$Foswiki::cfg{PasswordManager} = 'Foswiki::Users::HtPasswdUser';
$Foswiki::cfg{UserMappingManager} = 'Foswiki::Users::TopicUserMapping';
I uncomment the line as you write amail before:
Simply uncomment the return in $this->{CACHED} in
http://trac.foswiki.org/browser/trunk/TopicUserMappingContrib/lib/Foswiki/Users/TopicUserMapping.pm#L1529
and it seems to solve the problem for now ... a litle bit frustrated about such a magic BUG? in the new major release but also happy about the good and quick support.
--
GuentherFischer - 18 Oct 2010
If you can reproduce the bug by creating some more then 10 Groups there should be a patch release in a short time. If I can help with more testing let me know.
--
GuentherFischer - 18 Oct 2010
--
GuentherFischer - 18 Oct 2010
Hi again,
I do some more tests ...
I does copy some more Groups to Foswiki-1.1.0 and see now:
- before uncomment the line above I has an upgrade button in the GroupsList for all old Group's
- now this botton is missing
So I think it helps me to go forward, but it is not the real solution ?!
Is there a script to convert old Groups to new (all data in the META)?
--
GuentherFischer - 18 Oct 2010
On my server it takes a little more than 30 seconds to show
WikiGroups with 220 groups.
I have attached a zip with 220 or so groups and a couple of users. This can help Oliver and others reproducing and now I have created them, it can save others time doing the same.
--
KennethLavrsen - 18 Oct 2010
Oliver, I've checked in the one-line fix reactivating the cache.
--
GeorgeClark - 18 Oct 2010
I have checked the time it takes to render
WikiGroups with or without the cache and it still takes 33 seconds
If I view the topic as guest so I have no access to changing the groups the same topic loads in 10 seconds
I think the problem is the way we have built the user interface. We end up adding 220 Twisties in this case and 220 buttons
I think we may need to rethink this.
I reuploaded the zip with the many groups . the first had access rights for viewing the topic which was a hack I had tried earlier to root cause another bug
--
KennethLavrsen - 18 Oct 2010
I've committed a small change to GroupViewTemplate and WikiGroups. This adds another parameter
%maint%
. If maint is set to
off
, all of the twisties and individual group maintenance forms are not included. On my test system, for the 220 groups, it reduced page load time from 23 seconds to approx. 4 seconds. (from yslow).
--
GeorgeClark - 19 Oct 2010
I take the changed files
TopicUserMapping.pm,
GroupViewTemplate and
WikiGroups from
trunk/ and it works for me. I see all the upgrade buttons and the add/remove buttons in the upgraded groups. The time needed for
WikiGroups is 10-12 seconds.
In this context: I have TWiki/Foswiki since 2003. So there are different lines in ther
WikiUsers like
The first a Regsitration for extern users (htpasswd), the second local user with Shiboleth Auth and the third old Regstration (htpasswd).
I use "$Foswiki::cfg{Register}{AllowLoginName} = 1;" since Foswiki and
ShibLoginManager.
Could this make your Algorithm slow? Should I consolidate ...
--
GuentherFischer - 19 Oct 2010
Guenther - if you are down at 10-12 seconds with 200 groups and still having the twisties for adding and removing group members visible, then I guess it was the re-enabling of the cache that did the trick for you.
With respect to the extra setting to turn off the UI for adding/removing users from groups, I see it a bit as an emergency hack and I hope UI innovators like
ArthurClemens may come up with a new idea. It could be that instead of 200 twisties we could have a small piece of JS that calls up the UI when needed via rest or similar. There must be other ways that do not put such a load on server and browser.
Guenther - you can always try to manually update your
WikiUsers topic but I doubt this was the root cause because the groups consists of WikiNames so there should be no translation needed between canonical/login IDs to WikiNames in the process of listing group members.
--
KennethLavrsen - 19 Oct 2010
Kenneth, George, Oliver, Olivier - thank you for your help. I hope the patch will be visible for other Foswiki-1.1.0 downloaders in a short time ...
BTW - with enabling cache the
WikiGroups with less time (2 sec or so) if no group has changed ...
--
GuentherFischer - 19 Oct 2010
I have to add another problem.
- I see duplicate username in the groups - I think there is another Task !?
- I can't remove users from the group:
- I test to add -> it works
- I test to remove this user it works
If I look in the real text file with vim, I see the names in form of
Main.UserName
.
Then I remove all
Main.
pattern in the setting. After that I can remove the usernames from the group. But I think the form
Main.UserName
should work ...
--
GuentherFischer - 19 Oct 2010
It is very important for us to track issues that each bug has its own bug report.
So we need a new bug report for the above.
--
KennethLavrsen - 19 Oct 2010
I am closing this now as Waiting For Release.
I have done many fixes that may also fix the problem Guenther added. The duplicate users should be fixed I believe.
Guenther try and apply the fixes for
Item9848 and see if you still have problem. If so open new bug report.
--
KennethLavrsen - 20 Oct 2010