[Deploying Sakai] [Building Sakai] Sakai 2.9.x Kernel, Sessions, and WebDAV

Matthew Jones matthew at longsight.com
Fri Jun 21 08:33:35 PDT 2013

For an extended summary, many schools and Sakai installs didn't see the
gigantic increase in sessions as reported in KNL-1035. However this fix
lead down a road that ultimately caused webdav to no longer work after the
second connection and caused a problem storing the sessions. We monitor
sessions at Longsight and I've never seen that issue on any of our servers.
I did see it at Michigan but it wasn't consistent, and didn't happen all of
the time. This was decided on the release call Thursday (as Sam mentioned)
to be the easiest of the 3 options forward in resolving the login issue
with webdav to keep 2.9 stable. (A bigger problem overall than incorrectly
reported session counts)

The only way it really seemed like it could be a problem (excessive
sessions) is if one of the catches in SessionComponent were hit from the
Exception. There was a
                 } catch (NoSuchAlgorithmException e) {
and a
                 } catch (UnsupportedEncodingException e) {
Both of which silently failed prior to these changse, returning a new Uuid
(new session) every time someone tried to establish a session with webdav.
This could happen if the SHA-1 algorithm was not supported or UTF-8
encoding was not supported. UTF-8 should always be available but I'm not
100% sure about SHA-1 (though Stephen reported this should also be
available as of Java 1.4)

With these rollbacks, there is will still be warning in the log.

                         M_log.warn("makeSessionId fallback to Uuid!",e);

After applying this rollback, if your sessions are abnormally high, look
for this warning and let us know what the exception is. If your sessions
are abnormally high without this warning . . . Then I guess we'll have to
figure it out if/when that happens. That may involve applying some of this
work again, as long as it doesn't have all of the unintended side effects.

On Fri, Jun 21, 2013 at 11:02 AM, Sam Ottenhoff <ottenhoff at longsight.com>wrote:

> Stephen Marquard reported that WebDAV in 2.9.x and trunk was broken almost
> two weeks ago.  I would argue that two weeks to fix a large regression in
> 2.9.x is too slow not too fast.  That said, on our CLE Team call yesterday
> we agreed that we would like to see more work done on the KNL-1035 and
> don't want to see it ignored because of the rollback.  We would appreciate
> any help around a better solution for the root problem that doesn't regress
> any existing functionality.
> --Sam
> On Fri, Jun 21, 2013 at 10:51 AM, Niebel, William (wdn5e) <
> wdn5e at eservices.virginia.edu> wrote:
>>  I think you were a little fast on this change.  I had been asked to
>> review.
>> Just to be clear, I'm not saying I disagree with what was done, since I
>> haven't looked at it.
>> Bill
>>  ------------------------------
>> *From:* sakai-dev-bounces at collab.sakaiproject.org [
>> sakai-dev-bounces at collab.sakaiproject.org] on behalf of Sam Ottenhoff [
>> ottenhoff at longsight.com]
>> *Sent:* Thursday, June 20, 2013 5:53 PM
>> *To:* Matthew Jones
>> *Cc:* production-request at collab.sakaiproject.org; Developers Sakai-Dev
>> *Subject:* Re: [Building Sakai] Sakai 2.9.x Kernel, Sessions, and WebDAV
>>   KNL-1035 and KNL-1050 (minus logging statements) have been reverse
>> merged from trunk and kernel 1.3.x.
>>  KNL-1089 should now be considered resolved (incorporated).  Testing is
>> always appreciated.
>>  --Sam
>> On Thu, Jun 20, 2013 at 12:25 PM, Matthew Jones <matthew at longsight.com>wrote:
>>> In https://jira.sakaiproject.org/browse/KNL-1050 logs were added to the
>>> catches. These will be retained but the rest of KNL-1050 (that cuts the
>>> session) will not be.
>>> On Thu, Jun 20, 2013 at 12:20 PM, Neal Caidin <
>>> nealcaidin at sakaifoundation.org> wrote:
>>>> Looping in the production list on this one. Please see below.
>>>>  FYI - The motivation for this change is so we (the community) can
>>>> figure out the root cause of this problem, instead of just addressing the
>>>> symptoms.
>>>>  Question for Sam - How will logging get added so that the root cause
>>>> can be discovered?
>>>>  Thanks,
>>>> Neal
>>>>  On Thu, Jun 20, 2013 at 12:02 PM, Sam Ottenhoff <
>>>> ottenhoff at longsight.com> wrote:
>>>>>  There is currently a bug with successive WebDAV sessions in Sakai
>>>>> 2.9.2 described here:
>>>>>    https://jira.sakaiproject.org/browse/KNL-1089
>>>>>  We discussed the bug on this morning's CLE Team call and came to a
>>>>> general consensus that we would roll back several kernel commits that
>>>>> modified the way sessions behave in Sakai 2.9+.
>>>>>  The original work was done to limit the number of concurrent
>>>>> sessions by a user as some institutions had reported seeing thousands of
>>>>> sessions for some users.  That work was done here:
>>>>>  https://jira.sakaiproject.org/browse/KNL-1035
>>>>>  If you disagree with our intention to rollback this work in Sakai
>>>>> 2.9.x to resolve KNL-1089, please speak up.  If your institution has seen
>>>>> the symptoms described by KNL-1035, please speak up, add comments, and help
>>>>> us resolve that issue in a satisfactory way.  As discussed on this
>>>>> morning's call, we would still like to see a full solution to KNL-1035.
>>>>>  Thanks,
>>>>> Sam
>>>>>  _______________________________________________
>>>>> 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"
>>>> --
>>>> Neal Caidin
>>>> Sakai CLE Community Coordinator
>>>> nealcaidin at sakaifoundation.org
>>>> skype: nealkdin
>>>> _______________________________________________
>>>> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20130621/8cf62791/attachment-0001.html 

More information about the production mailing list