Uploaded image for project: 'Continuum'
  1. Continuum
  2. CONTINUUM-2195

adding a new schedule does not work on first activation

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.3.3 (Beta)
    • 1.3.4 (Beta)
    • Core system
    • None

    Description

      When the schedule was first created (with no projects assigned), it was "activated". However, after assigning a project to it, it did not fire. Editing the schedule (no changes made), caused it to fire on the assigned project. The log is as follows:

      2009-04-22 20:03:51,005 [btpool0-1] INFO  org.apache.maven.continuum.build.settings.DefaultSchedulesActivator  - Activating schedule minutely
      2009-04-22 20:37:13,488 [btpool0-7] INFO  org.apache.maven.continuum.build.settings.DefaultSchedulesActivator  - Deactivating schedule minutely
      2009-04-22 20:37:13,488 [btpool0-7] INFO  org.apache.maven.continuum.build.settings.DefaultSchedulesActivator  - Stopping active schedule "minutely".
      2009-04-22 20:37:13,488 [btpool0-7] INFO  org.apache.maven.continuum.build.settings.DefaultSchedulesActivator  - Activating schedule minutely
      2009-04-22 20:37:13,494 [btpool0-7] INFO  org.apache.maven.continuum.build.settings.DefaultSchedulesActivator  - minutely: next fire time ->Wed Apr 22 20:38:00 EST 2009
      2009-04-22 20:38:00,019 [continuumScheduler_Worker-4] INFO  org.apache.maven.continuum.build.settings.DefaultSchedulesActivator  - >>>>>>>>>>>>>>>>>>>>> Executing build job (minutely)...
      

      Attachments

        Activity

          Actually Continuum add a schedule is associated with a buildDefinition or purge process. Then you need an enable disable previously if it was not associated with a project. I think there are two possible solutions:
          1.- When whe updated or add a new build definition or purge process we would check if associated schedule jobs is in queuue (pending to execute) and enable/disable it.
          2.- Always (active = true) enqueue 2 jobs, first for buildProcess and second for purge process. They check if there are associated elements to execute process.

          What solution do you think is better?

          jomm Jose Morales Martinez added a comment - Actually Continuum add a schedule is associated with a buildDefinition or purge process. Then you need an enable disable previously if it was not associated with a project. I think there are two possible solutions: 1.- When whe updated or add a new build definition or purge process we would check if associated schedule jobs is in queuue (pending to execute) and enable/disable it. 2.- Always (active = true) enqueue 2 jobs, first for buildProcess and second for purge process. They check if there are associated elements to execute process. What solution do you think is better?
          wsmoak Wendy Smoak added a comment -

          without looking at the code, I'm leaning towards ...

          3. Move the code that "checks" somewhere it can be shared between (1) and (2)

          As written,
          (1) sounds to me like it will add a duplicate check
          (2) sounds like you're relying on a side effect of some other process, which will be confusing

          wsmoak Wendy Smoak added a comment - without looking at the code, I'm leaning towards ... 3. Move the code that "checks" somewhere it can be shared between (1) and (2) As written, (1) sounds to me like it will add a duplicate check (2) sounds like you're relying on a side effect of some other process, which will be confusing

          Sorry, but I think I have not explained:
          Currently only when we enable a schedule we add a job to scheduler(application scheduler- quartz ). Performing the following checks:

          if ( isScheduleFromBuildJob( schedule ) )
          {
            // A buildDefinition with this schedule
            schedule( schedule, continuum, ContinuumBuildJob.class );
          }
          
          if ( isScheduleFromPurgeJob( schedule ) )
          {
            // A purge with this schedule
            schedule( schedule, continuum, ContinuumPurgeJob.class );
          }
          

          That way if the schedule is not linked to a buildDefinition or purgeConfiguration not work for them. After set a schedule for a buildDefinition/purgeConfiguration we need to update the schedule to add job(s) to application scheduler.

          In this way, my options are:
          1 - Always add the job (buildDefinition and purgeConfiguration) to the scheduler. Simpler and does not modify the code to buildDefinition and purgeConfiguration
          2 - When a store purgeConfiguration / buildDefinition set a schedule we add job to application scheduler. More efficient (the scheduler only contains the jobs to be executed)
          3 - Add a single job for application scheduler and its execution launch a thread for builds and other for purge. This solution is similar to the first.

          jomm Jose Morales Martinez added a comment - Sorry, but I think I have not explained: Currently only when we enable a schedule we add a job to scheduler(application scheduler- quartz ). Performing the following checks: if ( isScheduleFromBuildJob( schedule ) ) { // A buildDefinition with this schedule schedule( schedule, continuum, ContinuumBuildJob.class ); } if ( isScheduleFromPurgeJob( schedule ) ) { // A purge with this schedule schedule( schedule, continuum, ContinuumPurgeJob.class ); } That way if the schedule is not linked to a buildDefinition or purgeConfiguration not work for them. After set a schedule for a buildDefinition/purgeConfiguration we need to update the schedule to add job(s) to application scheduler. In this way, my options are: 1 - Always add the job (buildDefinition and purgeConfiguration) to the scheduler. Simpler and does not modify the code to buildDefinition and purgeConfiguration 2 - When a store purgeConfiguration / buildDefinition set a schedule we add job to application scheduler. More efficient (the scheduler only contains the jobs to be executed) 3 - Add a single job for application scheduler and its execution launch a thread for builds and other for purge. This solution is similar to the first.

          I think i'll go with [2].

          After setting a schedule on a purgeConfiguration or buildDefinition, we add another call to schedule the job.

          Same goes when unsetting a schedule on purgeConfiguration/buildDefinition, scheduled job should be removed.

          ctan Maria Catherine R. Tan added a comment - I think i'll go with [2] . After setting a schedule on a purgeConfiguration or buildDefinition, we add another call to schedule the job. Same goes when unsetting a schedule on purgeConfiguration/buildDefinition, scheduled job should be removed.

          Fixed in :

          r780709 of branch 1.3.x
          r780735 of version 1.4.0

          jomm Jose Morales Martinez added a comment - Fixed in : r780709 of branch 1.3.x r780735 of version 1.4.0

          People

            jomm Jose Morales Martinez
            brett Brett Porter
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: