[Building Sakai] [WG: Sakai QA] Webdav protocol inconsistencies between QA servers.
Berg, A.M.
A.M.Berg at uva.nl
Wed Jan 6 08:43:37 PST 2010
Hi Jean Francois,
I believe you said that sak-5075 was added to trunk. I just tested trunk behind Apache and it passed one more litmus test (copymove 10) compared to 2-7.0 M2. There was also mentioned some logging for Fatal, but that feels like it is using stdout rather than log4j.
Find enclosed results. At the very least the Fatal error should give more context information for system admins.
qa1-nl column are the old results. new:8080 is without Apache on qa1-nl trunk and mod_jk is with Apache.
2010-01-06 17:07:36,561 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:36,568 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
[Fatal Error] :1:6: XML document structures must start and end within the same entity.
[Fatal Error] :1:57: The value of the attribute "prefix="xmlns",localpart="bar",rawname="xmlns:bar"" is invalid. Prefixed namespace bindings may not be empty.
2010-01-06 17:07:37,308 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:37,433 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:37,886 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:38,304 WARN http-8080-Processor19 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:38,328 WARN http-8080-Processor19 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
[Fatal Error] :1:1: Premature end of file.
2010-01-06 17:07:38,756 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:38,982 WARN http-8080-Processor19 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:39,129 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:39,169 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:39,276 WARN http-8080-Processor21 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:39,552 WARN http-8080-Processor20 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:39,919 WARN http-8080-Processor19 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
2010-01-06 17:07:39,955 WARN http-8080-Processor19 org.sakaiproject.content.impl.BaseContentService - SiteService could not find the site type
[Fatal Error] :1:1: Premature end of file.
[Fatal Error] :1:1: Premature end of file.
Alan
Alan Berg
Interim QA Director - The Sakai Foundation
Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam
http://home.uva.nl/a.m.berg
-----Original Message-----
From: Jean-Francois Leveque [mailto:jean-francois.leveque at upmc.fr]
Sent: Tue 1/5/2010 11:06
To: Berg, A.M.
Cc: Charles Hedrick; Sakai QA; Sakai Mailing List Dev
Subject: Re: [WG: Sakai QA] Webdav protocol inconsistencies between QA servers.
Hi all,
Alan, I think one of the differences related to mod_jk may come from the
fact that the fix for http://jira.sakaiproject.org/browse/SAK-5075 has
not been included yet even if reviewed and used by others than the lead
for Webdav.
I've been using it since 2.4.x without problems in Apache HTTPD versions
older than 2.2.8 (I currently use 2.2.3 with mod_proxy_ajp). Others than
myself have commented that it's safe and advocated for its inclusion.
Is there any reason not to include this fix?
Maybe the Sakai version, Mod_jk and SSL information could be added with
each server ID and we could sort by most failure-related parameters to
get a better picture. What do you think, Alan?
Cheers,
J-F
Berg, A.M. a écrit :
> Hi all,
>
> More for background information: I have checked various Sakai Qa servers
> including nightly for webdav protocol compatibility via the litmus tool
> and then parsed the results into an HTML table
> (http://builds.sakaiproject.org/litmus/2010/1/). There is some variation
> between servers due to what I assume is Sakai version, Mod_jk and SSL
> connections and other unknown factors. Therefore, if you are debugging
> webdav/browser issues it is well worth checking across a range of
> relevant servers.
>
> I will write a Jira that is unassigned and if anyone works towards
> improving protocol consistency can then use it to act as an umbrella.
>
> Alan
>
> Alan Berg
> Interim QA Director - The Sakai Foundation
>
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
>
> http://home.uva.nl/a.m.berg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100106/99d509e8/attachment.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100106/99d509e8/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: litmus.css
Type: text/css
Size: 1104 bytes
Desc: litmus.css
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100106/99d509e8/attachment.css
More information about the sakai-dev
mailing list