Executors

Overview

For this project you will write a client-server program to test several of ExecutorService-based server implementations. You will make four implementations of the following Java Interface:

public interface ServerInterface {
    /** See java.util.concurrent.Future<String>.get() for documentation
     *  on return value and exceptions thrown.
     *  @param task is the task to run in the server via task.call().
    **/
    public Integer submit(Callable<Integer> task)
        throws CancellationException, // if the computation was cancelled
            ExecutionException, // if the computation threw an exception
            InterruptedException // if the server thread was interrupted
        ;

    /**
     *  Shut down the server. Applications must generally shut down a
     *  server to terminate the process, since the server uses non-daemon
     *  threads.
     *  @param force if false use ExecutorService.shutdown(), and
     *  if true use ExecutorService.shutdownNow().
    **/
    public void shutdown(boolean force);
}

The implementations use the following thread pool methods:

• NoThreadPool: a baseline implementation that uses no threads.
• SingleThreadPool
• FixedThreadPool
• CachedThreadPool

The driver program must take the following command line arguments, in this specific order:

• number of threads: (integer) number of client threads to use
• thread pool method: (string) one of the above strings corresponding to the pool method.
• number of requests: (integer) number of requests each client makes.
• seed: (integer) seed for a random number generator.

The general flow of the driver program is:

• Parse command line arguments.

• Create the appropriate server object.

• Create the client threads; wait until all threads are created before starting them.

• Each client thread submits a number of requests to the server based on the appropriate command line argument.

  • For each request, generate a random integer between 0 and 47
  • Construct a Callable to submit to the server. The Callable must compute the nth value of the fibonacci sequence using the naive recursive implementation based on the random integer from the previous step.

• When all threads are done, output the results for each client and then shut down the server.

Example output:

$ java -cp .. project4.Main 4 NoThreadPool 5 42
Client 0 result[0] = 121393
Client 0 result[1] = 196418
Client 0 result[2] = 0
Client 0 result[3] = 6765
Client 0 result[4] = 2584
Client 1 result[0] = 121393
Client 1 result[1] = 196418
Client 1 result[2] = 0
Client 1 result[3] = 6765
Client 1 result[4] = 2584
Client 2 result[0] = 121393
Client 2 result[1] = 196418
Client 2 result[2] = 0
Client 2 result[3] = 6765
Client 2 result[4] = 2584
Client 3 result[0] = 121393
Client 3 result[1] = 196418
Client 3 result[2] = 0
Client 3 result[3] = 6765
Client 3 result[4] = 2584

Turning in the Assignment

For this assignment, you must turn in a zip file of a directory named project4 containing the following:

• Java source files
• Makefile
• README – include a description of design decisions and any observations from testing the program with the different server implementations.

Submit the zip file to the appropriate folder on D2L.

Total Points: 50

Program Correctness (20 points)

This evaluates whether your program works as intended. It is based on the results of automated tests that check if your code implements all required functionality correctly. This category also includes any additional issues not explicitly tested but that might lead to incorrect behavior.

Program Design (15 points)

This evaluates the overall structure and organization of your code. A well-designed program will typically have:

• Small, self-contained functions that perform specific tasks and are easy to test
• Common code factored out into reusable functions, avoiding repetition
• Flexibility to handle different use cases
• Low coupling between components (such as functions and classes), where each component only interacts with others through their public interfaces, not their internal details

Code Readability & Style (5 points)

This evaluates how easy it is to read and understand your code, as well as how well you adhere to the style guide. The key points to consider are:

• Clarity: Code should be clear and easy to follow. Avoid unclear variable names, magic numbers, and convoluted logic, etc.
• Style Consistency: While it’s not necessary to follow every single aspect of the style guide, your code should maintain consistency and follow the general principles outlined.

Documentation & Comments (5 points)

This measures how well your code is documented. At a minimum, your code should:

• Adhere to the department documentation standards.
• For each file, begin with a header comment that includes your name, file name, and a description of the file’s purpose. You may also include other details like the date written, your approach, or any references to resources you used.
• Contain comments within the code, especially for complex or unclear sections. Try to comment on parts of the code you may not understand when revisiting it in the future. However, avoid excessive comments—focus on clarity, not redundancy.

Adherence to Additional Specifications (5 points)

This checks whether you’ve followed all other requirements outside the coding task itself. For example:

• Correct file names or formats
• Any additional instructions or constraints given in the assignment

Important Notes:

• Broken Code: Submitting code that cannot be executed due to syntax errors or other issues will result in point deductions. If the code is so broken that it cannot be fixed easily, it will not be graded, and you will receive a zero for the assignment.

• Ambiguous Specifications: If a specification is unclear, you can either make a reasonable assumption based on your understanding or ask the instructor. If you make an assumption, be sure to note it in a comment so the reviewer understands your reasoning. However, poor assumptions may result in point deductions.