flock0 / eth-asl Goto Github PK

Critical sections shouldn't contain expensive logging lines.
Either only print every x-thousand iterations or save the data to main memory and log it afterwards.

middleware has to support the fact that previously stored items can be evicted from the
memcached servers over time, in which case the answer to a GET is an \empty" message (see
protocol description 7). This behavior can happen both with single-key and multi-key GETs.

arbitrary key and value sizes smaller or equal to 1024B in size.

The memcached servers can also send a NOT_STORED answer. We should treat this as an error. (Check the protocol specifications for details).

Each worker thread has a dedicated TCP connection to every memcached server. These
connections are set up when the middleware is started and they are only closed when the
middleware shuts down.

Requests are sent by the worker threads to the servers according to the specications
mentioned above. Worker threads wait until an operation has been completed and send
the answer from the server to the client before handling the next request.

This was a hint from the TAs. Make sure we always write all the bytes from our buffer. Do it in a loop. Don't rely only on a single write.

Try to work with the same ByteBuffer as long as possible.

see project description document from GDrive

Therefore, the
middleware code needs to be instrumented and report several metrics. Note that due to the
multi-threaded architecture of the middleware, statistics should be collected per each thread
and merged together when the middleware is stopped.
The middleware has to collect aggregate statistics per, at most, ve second windows. These
statistics must include:

• Average throughput
• Average queue length
• Average waiting time in the queue
• Average service time of the memcached servers
• Number of GET, SET, and multi-GET operations

At the end of the experiment, the middleware has to output, in addition to the previously
described statistics, the following:

• Histogram of the response times in tenth of a millisecond (100�s) steps
• Cache miss ratio (i.e., \empty" responses returned by the memcache servers)
• Any error message or exception that occurred during the experiment

The middleware forwards the requests to all servers in order
to replicate the data, and waits for a response from all of them. For successfully replicating
data, your middleware needs to perform the following:

1. Recognize a SET operation encoded possibly in multiple network packets.
2. The middleware has to forward the complete SET request to all memcached servers.
   It sends it to all memcached servers before checking for an answer.
3. Wait until all memcached servers report successful execution, a send a single success
   message to the client (in the same format as memcached would).
4. In case of an error on one or multiple servers, relay one of the error messages.

Opens up a TCP socket, takes request and puts them into the queue.

The middleware accepts connections and requests from clients on a TCP port of your
choice, specied when you launch the middleware. There is a single thread (net-thread)
that listens for incoming requests on the specied port and enqueues them into the request
queue.

The middleware has to be parameterizable at startup using three parameters:

L: Address to listen on.
P: Port to listen on.
T: Number of memcached servers.
M: IP addresses of the memcached servers.
T: Number of threads in the thread pool.
S: If multi-GETs are sharded.

At startup time, the middleware uses command line arguments to nd the set of servers
(at most 3) to connect to, and how many worker threads it should have. The net-thread
is always present.

There should be either a command line interface that allows stopping the middleware, or a
hook to catch a \kill" from Linux 8.

MULTI-GET: In the case of GET operations with multiple keys, the middleware has to
support two modes:

2. In the second mode (sharded read), the middleware splits the multi-GET into a set of
   smaller multi-GET requests (not single GET requests), one request for each server.
   The middleware should send out all requests before attempting to read answers
   from the servers. The middleware is responsible for assembling the responses and
   reordering values, if necessary, from all servers before sending the complete response
   of the initial multi-GET back to the client.

SocketsHandler> selector.select() method call.

Currently we use a catch-all for any type of exception and shut down the system.
Maybe we should handle ClosedSelector differently, i.e. keep a set ofo all sockets and recover by reinitialization of the selector.

Analogously we could handle ClosedSocket exceptions on the ServerSocketChannel by re-init. the ServerSocket.

ClosedSocketEx for the SocketChannels we can ignore, as this could mean, that the client has closed the connection.

For GET operations with a single key, the middleware acts as a load balancer and forwards
each request to only one of the servers. To distribute load equally you can choose to
implement either (a) a round-robin load balancer or (b) parse the keys and hash them to
determine the index of the server to read from. No load-dependent schemes are required.
We do expect, however, some proof that on average all memcached servers are subject to
the same load.

see Section 2 of the report outline for a description of what is asked.

Write up the section afterwards

Currently we are splitting up lines on \r\n. This could be unreliable when data blocks contain \r\n by chance.

For set commands, the size of the data block is known. When implementing set, keep that in mind and don't just check each line split by \r\n.

TA said on Oct 12: We don't have to guarantee fault tolerance. If errors occur: Best to keep code wrapped with try-catch, log the errors and then gracefully shutdown.

MULTI-GET: In the case of GET operations with multiple keys, the middleware has to
support two modes:

1. In the rst mode (non-sharded read), multi-GET operations are treated as regular
   requests and are forwarded to one server which handles the entire request. In this
   case, the answer from the server will contain multiple values and will be signicantly
   larger than a single value. Your middleware has to be able to handle up to 10 values
   in the same response.

based on issues

In addition to the metrics mentioned above, we encourage adding instrumentation to any
part of the project that is deemed important. Furthermore, we highly recommend using addi-
tional statistics and diagnostic tools (like dstat) to get additional insight (e.g., CPU utilization,
network bandwidth, etc.).

of all the experiments that need to be done

ATM we are creating a new worker object for each request.
Reverting back should speed things up.

Each worker thread in the thread pool must be able to handle all three types of requests
(SET, GET, multi-GET). If the clients send a request that does not belong to one of these
types, the worker thread has to record this event and discard data until a newline character
is encountered.

The net-thread puts all incoming requests into the internal request queue from which
requests are dequeued by worker-threads residing in a thread pool. The thread pool can
be xed size, but its size has to be a parameter given to the middleware at startup time.
A maximum number of 128 threads in this thread pool has to be supported.