XCTORY-1 Add unit tests to improve coverage
XCTORY-2 Add project creation and edition to the web UI
XCTORY-3 Add SCM integration
XCTORY-4 Improve Web UI
XCTORY-5 Authentication and Authorization
XCTORY-6 Add unit test to the web UI
XCTORY-7 Add form validation (client-side and server-side)
XCTORY-8 Review and document concurency
XCTORY-9 review agent and jobs model
Created by: xavier
on: 5/25/07
Updated by: xavier
on: 5/25/07
Assigned to: xavier

Introduce persistent based models, and decouple dynamic objects (JobAgent and Job) from their corresponding models (AgentModel and JobModel) so that we can keep an history of jobs, what happened in job lifecycle, list of agents with reconcilation at startup, and make the web site depend only on the model to ease clustering and decrease direct dependency and load on scheduler.
XCTORY-10 SCM Polling
XCTORY-11 review publishing architecture
XCTORY-12 JUnit reports
XCTORY-13 push is not working properly
XCTORY-14 use cometd as push mechanism
XCTORY-15 log auto update fix and improvement
XCTORY-16 Easy SCM URL configuration
XCTORY-17 deal with SCM authentication without displaying password in the SCM URL
XCTORY-18 change logs
XCTORY-19 remote agents
XCTORY-20 failure recovery
XCTORY-21 improve job distribution strategy
XCTORY-22 advanced job result sharing
XCTORY-23 user management UI
XCTORY-24 fine grain authorization based adaptation of UI
XCTORY-25 improve notifications
XCTORY-26 review concept of project: introduce job plan
XCTORY-27 search job plans
XCTORY-28 differential reporting
XCTORY-29 compilation report
XCTORY-30 workspace report
XCTORY-31 artifacts report
XCTORY-32 emma report
XCTORY-33 checkstyle report
XCTORY-34 PMD report
XCTORY-35 Findbugs report
XCTORY-36 javadoc report
XCTORY-37 replay job
XCTORY-38 label job
XCTORY-39 improve job progress bar
XCTORY-40 handle job dependencies
XCTORY-41 improve annotation results UI
XCTORY-42 Use Ivy to detect job dependencies
XCTORY-43 Improve annotation differential reporting
XCTORY-44 Review job plan page
XCTORY-45 Add summary tab to job page
XCTORY-46 Use change logs to fill in why and who fields in jobs
XCTORY-47 Add SCM logs to job logs
XCTORY-48 job activity
XCTORY-49 Improve change log details
XCTORY-50 Add inline documentation
XCTORY-51 Add success and failing time
XCTORY-52 Modularize xooctory

Enter new issue

[XCTORY-9] review agent and jobs model edit

Comments

xavier (5/25/07)

I’ve just checked in changes implementing this improvement. This is a major change in the code base, introducing some new concepts such as JobModel, JobLifecycleStep and AgentModel, but also simplifying it in other areas:

  • remove BuildProgressEvents (a build is just a subclass of Job, and thus all persistency and events are the same as for jobs)
  • remove JobRequest and subclasses: all information related to the requests are now stored as JobLifecycleStep, which are peristent and stored in a list, so we keep track of the whole history of the lifecycle of a job.

There is still some work to do:

  • there are some liveness issues with the AgentManagementService implementation under heavy load: it manage to deal with 50k events/s on my box, but with much more it can run into OutOfMEmoryError because the queue is not bounded
  • we should review the HibernateBuildManagementService, because some of the methods are not necessary any more now that a Build is a JobModel, using the JobDAO instead would be enough and less maintenance.
  • there may be issues with order of lifecycle steps, due to concurrency a step can be persisted after another one while it really should be before, which can cause problems about the status of the job, which directly depends on the steps.
  • we should improve live data reconciliation with the database: under heavy load the database view will probably become corrupted, so we should automatically check once a while if the DB state is consistent with the real data in the scheduler (about agent states especially). This doesn’t alter scheduler behavior (at least for the moment, because it relies only on its own view of the model, but this may change in the future, because handling thousands of agents in a list is not very good). But it will alter the web view of what’s going on in the system, which is not a good thing if the inconsistency lasts too long.
  • we should add a way to access directly to scheduler data (as was done before) from the admin page, with an option to call reconciliation manually.