Dynamic Scheduling and Load Balancing in Distributed Java Applications

1. Dynamic Scheduling and Load Balancing in Distributed Java Applications M. Muztaba Fuad Masters in Computer Science Department of Computer Science Adelaide University Supervised By Dr. Michael J. Oudshoorn Associate Professor Department of Computer Science

2. Overview • Motivation. • Other systems. • Goals. • Contribution. • Program structure. • System components. • Evaluation. • Conclusion.

3. Motivation • Most of the world’s PCs are idle most of the time. • By using this resource pool, an individual computation may be completed in a fraction of time. • A multi-threaded program can be distributed over a number of machines.

4. Motivation • A huge gap exists between a multi-threaded and a distributed Java application that forbids simple code transformation in order to build distributed applications from multi-threaded applications. • Distributing a program over a number of machines proves to be a tedious and difficult job.

5. Other Systems • New distributed programming environment • Java Party, Ajents. • Attempts to improve the underlying communication mechanism • ARMI, RRMI, Manta. • Only implement migration for load balancing • Mole, Aglets,D’Agents. • Take a completely different approach • Java/DSM.

6. Other Systems

7. Project Goals • Automatic distribution of user program. • Less programmer involvement for distribution of application across a network. • Identify situation of heavy load and migrate the application as necessary. • User should create distributed objects as local objects and distributed objects should behave as a local object. • 100% Java based system to support heterogeneous platforms.

8. Contribution • AdJava provides a system that makes it easy for programmers to convert a multi-threaded parallel program into distributable one. • The programmer does not need to worry about the distribution of the resulting program; AdJava deals with everything related to distribution on behalf of the programmer.

9. Contribution • AdJava provides transparent migration of objects to balance the load of the system. • AdJava provides support for remote input from files and output to console and files. • All this is provided without modifying the Java Virtual Machine.

10. System Architecture

11. Program Structure & Pre-processor • Using AdJava, programmers can easily turn a multi-threaded Java program in to a distributed program by identifying those objects that should be spread across the distributed environment. foo aObject = new foo (…);  classfooextends Thread  distributefooaObject = newfoo (…);

12. Local Objects Distributed Objects Remote method invocation Program Structure & Pre-processor … // Create five forks Fork f1= new Fork(1); Fork f2= new Fork(2); Fork f3= new Fork(3); Fork f4= new Fork(4); Fork f5= new Fork(5); // Assign Philosophers in proper places distribute Philosopher ph1 = new Philosopher(1,f1,f2); distribute Philosopher ph2 = new Philosopher(2,f2,f3); distribute Philosopher ph3 = new Philosopher(3,f3,f4); distribute Philosopher ph4 = new Philosopher(4,f4,f5); distribute Philosopher ph5 = new Philosopher(5,f5,f1); // Let them go ph1.start(); ph2.start(); ph3.start(); ph4.start(); ph5.start(); … class Philosopher extends Thread {……} … class Fork {……} …

13. Program Structure & Pre-processor … // Create five forks Fork f1= new Fork(1); Fork f2= new Fork(2); Fork f3= new Fork(3); Fork f4= new Fork(4); Fork f5= new Fork(5); // Assign Philosophers in proper places PhilosopherInterface ph1 = (PhilosopherInterface) Naming.lookup(host[0]); PhilosopherInterface ph2 = (PhilosopherInterface) Naming.lookup(host[1]); PhilosopherInterface ph3 = (PhilosopherInterface) Naming.lookup(host[2]); PhilosopherInterface ph4 = (PhilosopherInterface) Naming.lookup(host[3]); PhilosopherInterface ph5 = (PhilosopherInterface) Naming.lookup(host[4]); // Let them go ph1.init(1,f1,f2); ph1.init(2,f2,f3); ph1.init(3,f3,f4); ph1.init(4,f4,f5); ph1.init(5,f5,f1); … class Philosopher extends Thread implements PhilosopherInterface {… …} … class Fork implements ForkInterface {… …} …

14. Root Server • The root server has a well-known fixed address. • The root server executes the root daemon, which is responsible to setup and run the whole system. • The root daemon has two major threads that perform all background work once the system starts running.

15. sage radon argon Object 1 Current load = 90 % Current load = 20 % Current load = 30 % argon:6001/obj1 Object 2 radon:6002/obj2 Object 3 sage:6003/obj3 Object 4 argon:6004/obj4 Object 5 sage:6005/obj5 Root Server Object Distribution • Distribution of objects depends on: • Number of objects. • Number of hosts. • Load in each host. • Every host will have at least one object.

16. Agent Daemon Remote I/O Daemon Communication Daemon Communication port Remote Output port Migration port RMI Daemon Migration Daemon Agents • The agent is designed as a multi-threaded application where each of the threads has a specific job. • The agent monitors: • System load. • Communication from other agents. • Remote I/O. • Reference updating.

17. Migration • Java does not support access to the program stack and the program counter. • AdJava resumes threads only within the run method and not within other methods. • AdJava instruments its own program counter in the run method. • Suspend Serialize Transfer Resume. • Proxy objects are used for reference updating.

18. Remote I/O • From the perspective of the user on the root server, the remote object produces output and requests input as if it were actually executing upon the root server. • For file I/O, the target file is either copied to or copied from the remote host.

19. Graphical User Interface

20. Dinning Philosophers (5 Philosophers) Matrix Multiplication (600 x 600) Evaluation

21. Evaluation • Time to migrate an object

22. Evaluation • Code inflation due to pre-processing

23. Conclusion • This project develops an agent-based distributed architecture to distribute and manage Java applications automatically across a wide area network. • It has more features than other systems. • It performs well compared to other systems. • It is easy to use.

24. Future Work • Security • Fault Tolerance • Performance Optimization • Migration Improvement