Feature: Autograding Waiting Screen

[amartinez116]

Backend work for obtaining current job queue number from tango. Utilized Action Cable to deal with WebSockets in Rails which sends the info to _jobs_queue.html.erb a partial html file used in history.html. WebSockets send this information every 5 seconds through a 'rufus-scheduler'.

[amartinez116]

Currently, this information is shown at the bottom of the history handin page. (Which will change based on front end work). The code with this information is available through app/views/jobs_queues/_jobs_queue.html.erb

(Waiting Jobs are sent to tango in decreasing order of jobID even though they are misordered here. This list is just meant to showcase the jobIDs available.)

All this information is instantaneously refreshed every 5 seconds as can be seen through the "time created" field.

[victorhuangwq]

Description

This PR introduces the autograding waiting screen feature into the handin history page for autograded assignments.

The main purpose of having such an autograding waiting screen is such that

• users/students do not need to refresh their page to obtained their autograded score
• users/students who are new to autolab would know that they need to wait on handin history page / come back later
• provide users/students with real time feedback on the process of the grading

This features introduces two new complexities. It uses rufus-scheduler to ping the Tango server on an interval of 5 seconds. It also uses websockets to deliver the information to the student's waiting screens.

Motivation and Context

This enhancement is a result from our team's user interviews with professors and students who uses Autolab, who felt that

• refreshing to get score was not the ideal user experience
• new students do not know that they need to wait for their scores.

It should also address the following two issues: #965 and #33

How Has This Been Tested?

This feature has been tested in the following manners on a setup that uses latest Tango 2 (w/ python3):

1. submission of hello.c to this modified hello assessment hello_20200904.zip <-- i can only upload zips, so i zipped the tar.
2. submission of multiple hello.c to the modified hello assessment
3. submission of hello.c, closing the handin history page (or navigating out of the handin history page) and then coming back into the handin history page.

In Tango, when I was testing, I set the POOL_SIZE to be 1, so as to choke up the job queue faster, such that I can see the waiting screen's different states

Screenshots (if appropriate):

In queue, nth in line

In queue, next to be graded

While being autograded

Autograding complete

Banner on the assignment page if something is being autograded
This let's people who submitted using autolab-cli to be able to know about it as well

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation, which is located at Autolab Docs
• I have updated the documentation accordingly, and here is the corresponding pull request to Autolab Docs ->

[cg2v]

So, I'm really only looking at this because of concerns about rufus-scheduler on the Carnegie Mellon deployment (we use passenger, and the pointers on the rufus-scheduler page about working with passenger do not fill me with confidence), but I'm having trouble figuring out all the moving parts.

From what I can see, the rufus-scheduler is set up when assessments_controller is loaded (which means on passenger, multiple times).
Every 5 seconds it calls AssessmentChannel.speak, which adds a row to the jobs_queues table.
The JobsQueue after_create_commit callback invokes activejob to run the JobsQueueBroadcastJob
JobsQueueBroadcastJob.perform calls ActionCable.server.broadcast to send the messages to all subscribers

What cleans up the JobsQueue entries once they are no longer needed?
What is the purpose of using ActiveJob? Why can't AssessmentChannel.speak just do the broadcast itself?
Conversely, why not use ActiveJob to replace rufus-scheduler? It doesn't have an "every n seconds" model, but jobs can requeue themselves.

[victorhuangwq]

Hi @cg2v I think your concerns are valid, and I am currently looking to see how we can best change to an implementation that likely do not use rufus-scheduler.

Edit: Further looking into the issue, it seems that using issue with using rufus-scheduler with Phusion Passenger can be addressed with using

1. Using phusion passenger in direct mode https://stackoverflow.com/questions/21861387/rufus-cron-job-not-working-in-apache-passenger#answer-21868555 to prevent rufus_scheduler's thread from being closed
2. Using a lockfile https://github.com/jmettraux/rufus-scheduler#lockfile--mylockfiletxt to ensure that only one thread of rufus-scheduler is being spawned.

However, I don't think I have sufficient experience with production systems to understand the drawbacks (aside from the fact that people who deployed autolab has to change deployment settings perhaps), but @cg2v do you foresee other critical issues that might arise?

[victorhuangwq]

@michellexliu

[damianhxy]

Superseded by #1645