Continuum
  1. Continuum
  2. CONTINUUM-2195

adding a new schedule does not work on first activation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.3 (Beta)
    • Fix Version/s: 1.3.4 (Beta)
    • Component/s: Core system
    • Labels:
      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)...
      

        Activity

        Brett Porter created issue -
        Brett Porter made changes -
        Field Original Value New Value
        Fix Version/s 1.x [ 14167 ]
        Jose Morales Martinez made changes -
        Assignee Jose Morales Martinez [ jomm ]
        Hide
        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?

        Show
        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?
        Hide
        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

        Show
        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
        Hide
        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.

        Show
        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.
        Hide
        Maria Catherine 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.

        Show
        Maria Catherine 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.
        Jose Morales Martinez made changes -
        Fix Version/s 1.3.4 [ 15301 ]
        Affects Version/s 1.3.3 [ 15105 ]
        Affects Version/s 1.4.0 [ 15106 ]
        Fix Version/s 1.x [ 14167 ]
        Hide
        Jose Morales Martinez added a comment -

        Fixed in :

        r780709 of branch 1.3.x
        r780735 of version 1.4.0

        Show
        Jose Morales Martinez added a comment - Fixed in : r780709 of branch 1.3.x r780735 of version 1.4.0
        Jose Morales Martinez made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s 1.4.0 [ 15106 ]
        Resolution Fixed [ 1 ]
        Brett Porter made changes -
        Fix Version/s 1.4.0 [ 15106 ]
        Mark Thomas made changes -
        Project Import Sun Apr 05 08:36:01 UTC 2015 [ 1428222961749 ]
        Mark Thomas made changes -
        Workflow jira [ 12710847 ] Default workflow, editable Closed status [ 12740473 ]
        Mark Thomas made changes -
        Project Import Sun Apr 05 21:12:18 UTC 2015 [ 1428268338676 ]
        Mark Thomas made changes -
        Workflow jira [ 12948508 ] Default workflow, editable Closed status [ 12985764 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        40d 6h 27m 1 Jose Morales Martinez 01/Jun/09 12:28

          People

          • Assignee:
            Jose Morales Martinez
            Reporter:
            Brett Porter
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development