I'm looking to implement "Round Robin" Load Balancing in Java on a very simple HTTP web server.
Round Robin in this case would mean one HTTP request per port.
Say I have a webserver running 3 threads for 3 different ports each thread listening for a connection on that port. (This approach may be wrong.)
So a HTTP connection request comes in on a port, and say this needs 3 HTTP requests (a web page with 2 images for example). If this request came in on port 1234, for example, and my other 2 threads are sitting on 2 other ports doing nothing, how would I load balance this? So the first thread gets the first request, 2nd thread the next, 3rd the next, and back again. (If this is my correct understanding of round robin.)
You need two things :
1) You need a data structure which will rotate between the ports, in order, forever. This is known as a "circular data structure".
2) You will need to ensure that the data structure is shareable between threads, that is, that when one thread starts using a port for doing something, the data structure is notified of the fact that that port is busy, and then the particular port is locked.
A bare bones approach could be to use a synchronized circular queue here with locks in each of two slots.
Once you add each port's representative lock to the queue, you can have each thread lock that particular port while in use. Once the lock is released, the work can begin anew.
So first, we will create the queue to have 2 locks init, and the server will have an iterator in the queue.
When the request comes in - the thread will ask the server for a port. The server will check if the current (1st) slot is locked. If so , it will wait --- when unlocked, it will asynchronously give the lock to the thread, and increment position in the queue. The thread will then lock this resource, process the request, and unlock it. Once the thread finishes processing, it will unlock the resource. Meanwhile, if the 2nd thread comes, the server is free to assign the 2nd port, if that port is free.
Of course - there is a potential deadlock in your design here : if one thread never completes, the server will be stuck waiting for the lock to unlock before it increments to the next port.
http://www.koders.com/java/fid13E588928D0C01917AC9C30E35D802BDBA546368.aspx?s=Queue#L23