Catch a lot of old URL's and update them. Also remove a couple of old files that aren't used.
OK - I can still program Java, I just can't remember how this works :-)
Assuming I can still program in Java, these changes allow monitoring to be disabled at a per-host level or a per-host-per-monitor level.
Fairly major commit. This will break the current version of ihost, but this had to be done really to give Pete something to test the new ihost against. The main change here is removal of the TCP Heartbeat functionality from the filter. This meant the following features stopped working :- - Heartbeat testing - Configuration checking - Service checks The heartbeat testing, specifically the monitor, now looks at the presence of UDP packets instead. Before it just looked for the presence of a TCP heartbeat packet, so the change their is fairly negligible. Of course this means heartbeat testing now relies on the UDP working... but I don't see this as a problem. Configuration checking has been repositioned in to the filtermanager. This is a backwards compatible change - the filtermanager should still perform as it should for older hosts. But now there's an extra command to check the configuration is up-to-date, with a similar format to the old TCP protocol in the filter. (although we may optimise this soon) The service checks are broken. This isn't a major issue for us as they were pretty useless in the first place. The concept is good, but the checks are just far too primitive. I expect at some point I'll work on a seperate component that just monitors services, which will replace this function. Further changes in the server include removal of the key checking code, as this relied on a bolt on to the TCP heartbeat protocol to ship the key. This got more akward than originally planned, so I'm happy to drop the idea. In the long term we hope to replace this with a public key systems for signing and even encryption. Finally, general tidy up to remove other bits of code that check for TCP heartbeat packets when they don't need to any more.
Changed the server to use the external util package. Quite a minor change, but does affect a lot of files.
Added URL to GPL headers.
i-scream is now licensed under the GPL. I've added the GPL headers to every source file, and put a full copy of the license in the appropriate places. I think I've covered everything. This is going to be a mad commit ;)
Completing this feature request: [ #479631 ] heartbeat monitor - starting list Adds hosts defined in this configuration value to the heartbeat monitor on startup. Monitor.Heartbeat.initialHosts=raptor.ukc.ac.uk;myrtle.ukc.ac.uk This means the Heartbeat Monitor will generate heartbeat alerts if these hosts don't send in a heartbeat within the expected time. This is useful in situations where the i-scream server comes up after the hosts have gone down, which usually wouldn't have generated an alert - because the server would never have seen the hosts to know they're gone.
Major change in the java package naming. This has been held off for some time now, but it really needed doing. The future packaging of all i-scream products will be; uk.org.iscream.<product>.<subpart>.* In the case of the central monitoring system server this will be; uk.org.iscream.cms.server.* The whole server has been changed to follow this structure, and tested to a smallish extent. Further changes in other parts of the CMS will follow.
The "checking" part had moved from the main class to an inner class, thus the synchronize(this) blocks were pointing at different "this"'s. This how now been fixed, we hope.
Fully javadoc'd all the monitors. Also made a few little changes here and there, removing code that had been duplicated by copying other monitors, and tidying up any silly little things (such has hardcoded integer values).
Fixed inheritance bug.
Re-arranged...better layout.
For some reason this code wouldn't compile under FreeBSD without this change.
Now works with the new queue structure.
The whole server package structure has been changed. Old Package: uk.ac.ukc.iscream.* New Package: uk.org.iscream.*
TOTALLY re-wrote the Register class and made appropriate changes thoughout. It is now much more obvious what is going on in many places. The problem was probably caused by doing CPU as a first monitor and hard coding the number of attributes a Register stores. Now if a monitor wants to store multiple attributes, it has to do that itself. This makes alot of things much more readable and inteligable as a result.
A slight logic error. Should now properly count the time between heartbeats, and thus won't bypass thresholds when it shouldn't :)
The synchronization is causing delays. Looking at the analysePacket method, it only modifies the HashMap structure when a new host appears - which isn't very often relatively. Therefore, only that section is synchronized, meaning the new packets that arrive regularly will not have to wait for the "checking" thread. I'm hoping the logic behind the synchronization here works.
Added some synchronization. We managed to get a ConcurrentModificationException in the server :)
The threshold values now represent the time in seconds "since the heartbeat was expected". Before this change, you could set a value of less than the heartbeat period and alerts would be fired when the heartbeat is simply not due.
Changed the existing monitor's to use the skeleton class.
Now removes a host if it has reached the FINAL level.
Now passes the time since the first alert for a problem occoured. Also has support for formatting and displaying this information as obtained from the config
Forgot to prepend Host. to the TCPUpdateTime value.
Added error checking, and also changed to an "implements Runnable" Thread. This is because we may be moving to an abstract class soon.
Fixed to work. Had a bug with using int's instead of long's. Didn't actually start the thread. Needed a bit or error catching.
A monitor to watch Heartbeats. This has been built around the architecture of the CPU Monitor, in the hope that it'll later allow better abstraction. This may not fully work yet.
This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, select a symbolic revision name using the selection box, or choose 'Use Text Field' and enter a numeric revision.