Test plan passed on ctdev on site https://ctdev.ds.itd.umich.edu/portal/site/e84dab93-36b5-43f5-9bad-b62c99888f7c. Refer attachment for results

Here's a possible test case. In a site with at least one student member,

1. create an assessment with a single multiple-choice question.

2. publish the assessment

set the due and accept date to the same value-- ten minutes from now.

enter an email address into the "email results to" field.

3. become the student and take the assessment.

4. after the due/accept-until time passes, revisit the publish page for the assessment as the site owner.

the "email results to" field should now be followed by a button to "Email Again." I've never actually seen this work, but that's what Glenn says.

5. go to the gmail inbox for ct-dev.

there should be an email sent at the close time that includes a .csv attachment with the assessment results.

Merged to CTools-2.7.1 branch
r98941

Added property into instance.properties files for ctools, testctools, ctdev, ctint and ctload, in ctools-reference.
r98935.

Email conversation with Glenn:

From: "Glenn R. Golden" <ggolden@etudes.org>
Date: September 6, 2011 11:12:20 PM EDT
To: "Prakash, Savitha" <savithap@umich.edu>
Cc: Etudes <dev@etudes.org>
Subject: Re: [Building Sakai] Mneme configuration issue

Savitha -

Good questions!

The thread runs every 300 seconds (5 minutes). You can adjust this by sakai.properties, with the timeoutCheckSeconds setting on the SubmissionService. You want a balance between the work of checking too often, and then unresponsiveness of checking too infrequently.

You can see what it does in the SubmissionServiceImpl's run() method. It will make a db call to get submissions, and if it finds any, close them one by one.

I don't know about load testing. You would have to setup some timed or due-date submissions that are started and about to run out of time, and then let this thread close them. Stay away from the Mneme UI at this time, because bringing up lists of submissions by the student or instructor (in grading) will also auto-close things.

Since this will be running on only one app server in your cluster, you can keep an eye on it's performance. If they all started out pretty even, and this one starts to lag because of hosting this thread, that would be a sign.

The first time you run this, it may find a bunch of things to close - but again, since there are other ways for these to be auto-closed, your mileage will vary. You could opt to initially run this on an app server not in the active cluster, but hooked to the active database. That way it will get any catch-up work done without slowing down an app server (the database will still be involved).

• Glenn

Glenn R. Golden
Chief Architect, Etudes, Inc.
ggolden@etudes.org

On Sep 6, 2011, at 2:41 PM, Prakash, Savitha wrote:

Hi Glenn,

We are running 2.1.2 of Mneme, and we have not configured any property yet in our production instance. We are looking to incorporate the property and need more information.

• How often does the thread run to do the maintenance?

• How extensively does it check?

• What kind of load testing would require for us to test it out?

• What does is mean for us to introduce the property for the first time? I am guessing, our system will have to do lot of maintenance job for the first time, as there might be many open assessments, that needs to be closed.

Thanks,
Savitha