Team 1: Box Office : Analysis of Software Artifacts : Dependability Analysis of Middleware JunSuk Oh, YounBok Lee, KwangChun Lee, SoYoung Kim, JungHee Jo

2 Team Members JunSuk Oh YounBok Lee KwangChun Lee SoYoung Kim JungHee Jo

3 Baseline Application System description –Box Office is a system for users to search movie tickets and reserve tickets Base Features –A user can login –A user can search movies –A user can reserve tickets Configuration –Operating System Server: Windows 2000 Server, Windows XP Professional Client: Windows XP Professional –Language Java SDK –Middleware Enterprise Java Beans –Third-party Software Database: MySQL Web Application Server: Jboss Java-IDE: Eclipse, Netbean J2EE Eclipse Plug-in: Lomboz

4 Operating System –Easier to set up the development environment than Linux Cluster –Easier to handle by ourselves JBoss –Environment is supported by teaching assistants EJB –Popular technology in the industry, members’ preference MySQL –Easy to install and use –Easy to get the developing document Eclipse –All team members have experience in this technology Lomboz –Enables Java developers to build, test and deploy using J2EE Baseline Application - Configuration Selection Criteria

5 Baseline Architecture Client Tier Middle TierDB Tier DataBase J N D I cardinfo login movie reserv user Client Entity Beans Session Bean Entity Bean Client PoolDB Table session JNDI Lookup RPC DB Access

6 Fault-Tolerance Goals Replication Style –Passive Replication Approach –Replication 2 replicas are located on separate machines –Sacred Components Replication manager Database Client –Fault Detector Client –State All beans are stateless States are stored in the database

7 Client n FT-Baseline Architecture Sacred Fault Tolerant Database Factory Client side (Sacred) Client 2 Primary Replica Replication Manager Client 1 Machine 1 Machine 2 JNDI Backup Replica JNDI Factory

8 Mechanisms for Fail-Over (1) Fault Injector –Periodically, fault injector kills replica in turn (1 min) Replication manager –10 seconds after server fails, Replication Manager invokes factory to relaunch the failed replica. Fail-over mechanism –Fault detection –Replica location –Connection establishment –Retry Primary Replica Client Fail-Over Mechanism Factory Backup Replica Replication Manager Factory 1. Request 2. Server Failed Fault Injector Replicate Inject fault 4. Retry 3. Connection established

9 Mechanisms for Fail-Over (2) Fault Detection –Exception handling by Client RemoteException – NoSuchObjectException, ConnectException (RMI) NameNotFoundException (JNDI Failure) Replica location –Client knows the servers from whom it should request service Connection establishment –Get a connection to new replica –Server reference should be looked up: When client request the service for the first time When client detects server failure and try request to other server –Client retries the request to backup replica until service becomes available Retry –Request service again

10 Failover Mechanism (3) - Avoid Duplicate Transaction Target case –Transaction is stored in the DB but it cannot be informed to client Mechanism Client Server Database 1. Service request 2. Store to DB 3. Return result 4. Inform client Client Replica 1 Database 1. Request OP #15 2. Store OP #15 3. Success 4. Inform client Replica 2 5. Retry OP #15 6. Check Trx state 7. Duplicate 8. Duplicate

11 Fail-Over Measurements – High Peak: RemoteException – Low Peak: NameNotFoundException 200

12 Fail-Over Measurements FD: Fault Detect CE: Connection Establishment

13 RT-FT-Baseline Architecture Two steps to the Optimization –Step 1: Reduce the connection establishment time Client needs to reconnect to available replica after fault detection Pre-established connection: Connector on the client side will maintain the connection to each replica in the background ► Reconnection time disappeared but still graph shows spikes due to the time for catching connection exception –Step 2: Reduce the fault detection time Reducing the catching exception time –RemoteException – NoSuchObjectException, ConnectException Having fault detector on client side Fault detector will update the status of replicas periodically. Clients can know the status of replicas beforehand. ► Getting rid of fault detection time as well as spikes!!

14 RT-FT-Baseline Architecture Replica 1 Replica 2 Connector Client statusServer1 statusServer2 : Pinging for checking status : Establishing connection as background update checking Local FD

15 Bounded “Real-Time” Fail-Over Measurements Fail-over graphs after optimization step1 200

16 Bounded “Real-Time” Fail-Over Measurements Fail-over graphs after optimization step2 200

17 Analysis on Fail-over Optimization FD: Fault Detect CE: Connection Establishment Low PeaksHigh Peaks FDCERetryFDCERetry Before optimization16ms82ms116ms7661ms93ms123ms After optimization0ms 104ms0ms 104ms Reduction100% 10.34%100% 15.45% :Reduced part

18 High Performance: Load Balancing Distributed clients’ requests among multiple servers Having separate load balancer to control the access to the servers Strategy –Static load balancing Round Robin way Assign server in turns –Dynamic load balancing Load balancer periodically checks the current number of client of each server Dynamically assign the server to each client –Simulation strategy Measurements on the actual server A&B RTT Move to the SIMULATION environment Find the working load balancing strategy Confirm the load balancing strategy in the actual environment Find alternative load balancing strategies

19 Load Balancing Strategy Replica A Replica B Load Balancer 1. Which Server? 2. Server A 3. Connect Client 1Client 2Client N … 4. Which Server? 5. Server B 6. Connect Load Balancer 1. Which Server? 4. Server A 5. Connect Client 1Client 2Client N … 2. How many Clients? 3. Two 3. Ten Strategy 1 (Round Robin)Strategy 2 (Check for # of clients) Replica A Replica B

20 Performance Measurements replica a Client

21 Load Balancing Strategy Load balancing strategy by using historical data and simulation systems Testing load balancing strategy under the simulation environment Predict load balancing strategy performance Server A Server B Data Collection Load Balancing Algorithm Development Min Max Load Balancing Algorithm Algorithm Performance Prediction Round Robin Algorithm

22 More on Strategy Server A Server B Consider X clients Min Max Algorithm Y clients from Server A X-Y clients from Server B ALLOCATE Average Y Clients RTT Average X-Y Clients RTT RandomSamples RandomSamples Repeat 1000 Average RTT

23 Server A & B Performance Measurements (RTT)

24 Performance Measurements (II) Random Load Balancing Min Max Loading Balancing LP Load Balancing

25 Other Features Experimental Data from Server Algorithm Testing With Empirical Data & Parameter Updates Load Balancer Intelligence Update Server A Server B Server A Server B Client Client

26 Insights from Measurements FT –Two different types of peak were measured according to different exception. RT-FT –Connection Establishment time was removed Pre-connection before the failover. But, still high peak remained. –Fault Detection time was removed Watchdog before catching exception. RT-FT Performance –Round Robin is good for our situation Servers have similar capacity. –Load balancing algorithm can be selected considering running environment Test Environment –Keep clean environment to reduce jitter.

27 What we learned & accomplished What we learned? –How to handle JBoss First experience for majority of team members –Careful analysis of the test result definitely save the time –How to control the factors to get the better data What we accomplished? –FT Passive replication strategy Avoid duplicate transaction –RT-FT Pre-established connection strategy Local Fault Detector for checking status of server beforehand –Performance Implement Static Load Balancing Implement Dynamic Load Balancing Simulate several load balancing strategy

28 Open Issues & Future Challenge Open Issue –FindAll() doesn’t work on Jboss on Linux It works well on Windows OS –Implementing several load balancing strategy Min Max, LP (Linear Programming) algorithm Future Challenge –Separate JNDI service –Get server list from Replication Manager dynamically –Try Active Replication –Try development without IDE tool