[Deploying Sakai] [Building Sakai] Zombie sessions associated with WebDAV

[Beth Kirschner]

Michigan has also been seeing a high number of "zombie" sessions since we've upgraded to 2.9.0 (we leapfrogged from 2.7.2 to 2.9.0, so the problem could well have been introduced in 2.8). 

We'll be testing SAK-19592 to look at the possibility that "PROPFIND for a non-existant resource should return SC_BAD_REQUEST (not NOT_FOUND), to avoid problems with sessions not being cleared" -- but this is conjecture at this point, so we'll have to wait to see what difference this makes in testing and production.

Thanks Alan for the link to litmus test - we'll look into running that as well.

- Beth

On Mar 21, 2013, at 9:57 AM, Alan Berg <bergsmooth at gmail.com> wrote:

> I would run the litmus test against an acceptance machine and see if you can generate the same results.
> 
> http://www.webdav.org/neon/litmus/
> 
> 
> On 21 March 2013 14:51, Seth Theriault <slt at columbia.edu> wrote:
> Hello,
> 
> In a CLE call a few weeks ago, I mentioned that Columbia is seeing a
> large number of "zombie" sessions reported in the Online tool. For
> example, our local Sakai is currently reporting more than 163,000
> sessions, a clearly incorrect number since it is 5x the number of
> eligible users. In addition, the Apache logs confirm that these
> sessions are simply orphaned because there is no corresponding HTTP
> traffic; every once in a while, Sakai moves to close some of them.
> 
> This is 2.8.1 with local modifications. We started to see this
> behavior in January after an local upgrade, so we have suspected that
> a change to the local modifications is that the core of the problem,
> but no obvious things have revealed themselves. In addition, this JIRA
> shows similar behavior, but isn't restricted to WebDAV sessions:
> 
> https://jira.sakaiproject.org/browse/KNL-1035
> 
> Has anyone else seen this sort of behavior? Does anyone have any ideas
> about where the problems might be? The DAV module is notoriously
> problematic -- especially with the native OS clients -- so I am
> thinking that's the prime candidate.
> 
> Seth
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 
> 
> -- 
> Regards,
>        Alan
> 
> Alan Berg
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"