Implementation of the background service

A new class, DailyRDAHMMRunner, is added to Exec_RDAHMMService project, to run RDAHMM daily on all stations in background. This class contains a main() entry so that it can run as a stand alone process. This class creates a list of all stations with a state assigned to every station to denote if RDAHMM has been run “today” on this station. Initially every station’s state is assigned as waiting to be run. Then a specific number of threads (this number can be specified when the program is started) are created to run RDAHMM on a series of stations. Every station keeps trying to get the next waiting-to-be-run station from the list, runs RAHMM on it, and generates necessary results for the station. Once there are no waiting-to-be-run stations left in the list, the thread sleeps until the scheduled running time on “tomorrow”.

DailyRDAHMM portlet

I added a new "DailyRDAHMM" portlet to show the result of daily RDAHMM detection.

Upon the request of a browser, the portlet analyzes an xml file, which is generated after running daily rdahmm to record the status changes of stations, and shows the status changes in a similar way to the Realtime RDAHMM portlet. There is a mark for every station on the google map; a click on the mark shows the latest status change trace picture of that station. If the station has a status change from the day before to the present date, the corresponding mark has a red icon; if a status change is detected for a date in the history, the mark icon is yellow; green is used for no status change. Besides the map, a list containing all the stations with status changes and the date of the changes is shown on the right side of a web page.

A test example of this portlet can be accessed at http://156.56.104.131:8080/gridsphere/gridsphere?cid=DailyRDAHMM-Portlet . This example uses an arbitrary manually edited status-change xml file.

The codes for running rdahmm daily on all stations have not been completed, cause I got this problem of how to complete this daily schedule of invoking rdahmm services for all stations...I wonder if a standalone application should be added to call the service everyday. PS, since svn diff does not provide accurate information concerning the status changes and the date they happen, I think I'll just compare the files line by line, and just use svn to save the files.

a busy week

The page layout of daily RDAHMM detection will be similar to that of realtime RDAHMM, except that there will be an additional list to show all the stations for which state changes have been detected. So there is a lot to rely on in realtime RDAHMM. The invoking mode is also similar, just that daily detection needs a daily running schedule.

The daily detection portlet will always try to display the latest result. If the result for the current date is still not available, the previous day's result is given.

Got the os mid-term exam; not hard. Db mid-term is postponed, and this is not supposed to be a problem.