CIIC request.

Either https://github.com/Netflix/servo or https://dropwizard.github.io/metrics/

This also includes making sure all problem data is still consistent.

When diagnosing issues it is useful to know which machine will handle the request in order to get the logging information out.

:c

Turns out I only checked that puts "Hello, World!" worked under Minijail, but I never actually added all the magic incantations needed to compile or run ruby programs in Sandbox.scala.

https://omegaup.com/arena/problem/Karelquimedes/#runs

At the very least the places where a reply was expected and the other side died should all be RTE. Things like crashing or calling exit() will trigger this.

Chocar con paredes, poner zumbadores cuando no tienes, quitar zumbadores cuando no hay, acabarte el stack...

Shit happens. We should validate that all files have not been corrupted on startup.

This is a much better idea overall than #3.

For reasons still unknown, Linux sometimes does not open the pipes fast enough and spends ~5 seconds waiting for something to happen and then transfers control back to the program.

This seems to be mitigated by unlinking the pipes before each run.

While it is convenient to have them both run in the same service, forcing a restart on the Broadcaster every time an update to the grader is made is inefficient, since all long-lasting websockets connections die and need to be brought back up. This can be solved by deploying both as independent services (and probably even forego the need for running proguard and storing the .jars in the repository!).

It turns out that neither the IDL AST nor the Options objects are serializable as-is by Lift (curse you, type erasure!!!). It's going to be much simpler if we just ship the whole .idl and have the runner parse it instead of having to support JSON serialkzation/deserialization for those objects.

This is probably also in preparation for a revamped architecture that uses GRPC (and might even mean pull runners!).

C++, when calling abort(), invokes futex, tgkill and kill, all of them restricted syscalls. These syscalls can be marked as generating RTE to avoid confusion about RFE.

When bringing an old instance of a runner online, it will most likely have old versions of the code, and therefore will probably cause JEs until it is upgraded. A better deployment strategy (most likely using Puppet) is needed to ensure the runners are up to date before starting.

The goal is to have a fully self-contained backend. This means that it should be possible to install problems, send and view results of runs by using a REST API.

Since it is racy and has a 1s timeout, programs with a lot of cases have near-100% probability of exceeding the 60s maximum execution time.

Due to lousy connectivity on some users' machines, and that the Broadcaster is single-threaded and semi-blocking, the notifications are taking a long time to propagate.

Sometimes it is desirable to allocate a pool of runners to run only a handful of problems or handle a contest exclusively. Currently we can only assign runs to one of the six default queues, but it could be possible to create more queues connected to runner pools.

Having git as the problem store is desirable since we can easily perform versioning and have a little bit more integrity checks. Plus, having the inputs pre-zlibbed and hashed makes it easier to send the inputs without having to store a clunky .zip file + hash.

Codeforces y la UVa lo hacen, seguro hay más.

Como quiera, es conveniente para debugear y así.