SE401:Group33:Implementation Issues
Multi threading
(Nick) I discovered, while writing the simple control module class, that multi threading is hard :). The use of the synchronized keyword in method headers was causing deadlock, as it locks the whole class in order to execute the method. The way I wrote the code (not having a very good idea about synchronisation) meant that this was not going to work, and it stopped the starting of the HIDRA controller. The way in which I (fingers crossed..) fixed it was by implementing finer grained locking.
I created several lock variables, the important ones being sendLock and receiveLock. These are the variables that are locked in order to send or receive messages. Another important lock variable was isLeader. This variable is the lock on several sections of code, during which it makes no sense to change who the leader is.
Leader stuff
- When an instance is started, it listens to hear who the leader is. If the leader 'dies' after starting the instance but before communicating with it, then the new instance will think it is the leader and react appropriately. This is a problem with our implementation. One alternative is to rely on JGroups to figure out who the leader is using elastic IP addresses as well known hosts. Another is having the new instances always assume that a given elastic IP is always the leader.