I don't have any way to map from the regrading of a particular question to a JOBE log entry. There are two runs with a 765 byte payload, one with a 539 byte payload and two with a 1789 byte payload. I don't know if that's 3 questions, two with retries, or 5 questions with no retries.
The critical question here is whether the regrade of Q5 does or does not reach JOBE. That needs to be resolved definitively.
There are two possibilities:
The critical question here is whether the regrade of Q5 does or does not reach JOBE. That needs to be resolved definitively.
There are two possibilities:
- The request never reaches Jobe.
- The response never gets back to Moodle.
The OOM-killer theory is ruled out if it is guaranteed that one of those JOBE log entries corresponds to Q5, since all returned with a 200 OK response. So what might stop a request getting to JOBE or a response getting back? Is there a firewall/WAF/reverse proxy/load balancer in front of production Jobe that isn't in front of your test one? If so, worth checking its logs (not Jobe's) for both inbound and outbound traffic during a Q5 regrade— particularly anything about a reset, timeout, or oversized/blocked response.
Some things to possibly try:
- Customise Q5 and in Advanced customisation > Sandbox parameters set {"debug": 1} . Regrade Q5 for that one student (and maybe another student for comparison). Then on the Jobe server look in /home/jobe/runs (which you should also check before starting). The complete record of the run - code, compile output, run output etc - will be there if the job made it to Jobe. If there's nothing there, your theory that the job never makes it to Jobe is confirmed (though please double-check with a regrade of a question that works).
- Are you able to pull the current Development branch from GitHub ? If so, you'd get the exact cURL error message rather than the unhelpful 0:null response. But I'm guessing that's not possible?
- Look in /var/www/html/jobe/writable/logs for any error reports during regrades.
- Try to carry out the test I suggested earlier of switching your test server to use the same Jobe as the production server and see if you then get the 0: null response.