# The locations of the following directories may be configured here dir { # Grader jar ingest directory graders=graders # Runtime dependencies for submissions libs=libs # Rubrics export directory rubrics=rubrics # Submissions ingest directory submissions=submissions # Submission export directory submissions-export=submissions-export } executor { # # The maximum amount of concurrency to use for grading. # For a given concurrency n, Jagr will ensure that a maximum of n threads or processes are used concurrently that actively run # submission code. concurrency=4 # # The JVM arguments to use for grading. These arguments are passed to the JVM that runs the grading code. # This only applies to the "process" mode, as the "thread" and "single" modes do not spawn a new JVM. # jvm-args=[] # # The executor mode to use. The following options are available: # - "single" :: # Runs every TestCycle consecutively in the main thread. This mode does not create any extra processes or threads for grading. # # - "thread" :: # Creates a separate thread for every TestCycle. This mode greatly speeds up the grading process, especially with a large # amount of submissions. The overhead of creating, managing and synchronizing threads is minimal compared to the performance # benefits. However, this mode has the danger of creating "unkillable" threads (e.g. from certain kinds of infinite loops) # which dramatically slow down the grading process through resource starvation of the host machine. # # The maximum number of concurrent threads used for grading is defined by the option "concurrency". # # - "process" :: # Creates a separate process for every TestCycle. This mode has the most overhead, but is also the most defensive against # "badly behaving" code. A certain amount of sandboxing can be achieved in this mode, which is not possible in the other modes # such as "thread" or "single". # # The maximum number of concurrent child process used for grading is defined by the option "concurrency". mode=process # # The grading thread's maximum permitted elapsed userTime in milliseconds since the last timeout before an # AssertionFailedError is thrown. If a thread's userTime satisfies # (userTime - lastTimeout) > individualTimeout, # the current userTime is stored for comparison later, and an AssertionFailedError is thrown to be caught by JUnit. timeout-individual=10000 # # The grading thread's maximum permitted elapsed userTime in milliseconds (from thread start) before an # AssertionFailedError is thrown. If a thread's userTime satisfies # ((userTime - lastTimeout) > individualTimeout) && (userTime > totalTimeout), # an AssertionFailedError is thrown to be caught by JUnit. Note that lastTimeout is not reset in this case, and all further # invocations of checkTimeout() will result in an AssertionFailedError timeout-total=150000 } extras { moodle-unpack { assignment-id-regex=".*Abgabe[^0-9]*(?[0-9]{1,2}).*[.]zip" enabled=true student-regex=".* - (?([a-z]{2}[0-9]{2}[a-z]{4})|([a-z]+_[a-z]+))/submissions/.*[.]jar" } } transformers { timeout { enabled=true } }