[WG: Sakai QA] Webdav protocol inconsistencies between QA servers.

[Berg, A.M.]

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-qa/attachments/20100106/99d509e8/attachment-0002.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20100106/99d509e8/attachment-0003.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-qa/attachments/20100106/99d509e8/attachment-0001.css