14 Replies Latest reply on Mar 26, 2008 11:05 PM by aguizar

    timer update and questions

    tom.baeyens

      I changed the name of the timer class back to Timer. I can see that the name clashes with java.util.Timer. This is only an implementation problem on our side for the memory timer. I would like to expose the clean name 'Timer' to our users. Only name clashes with java.lang should be avoided at all times. But we have other situations where we have name clashes with jvm classes.

      First question is about eligebleDate

      /** date until which the command should not be executed
       * this date is set to the current time
       * It should be modified only for timers
       * Warning: if you modify this, be sure to wake the JobExecutor
       * when the job is supposed to be executed */
       protected Date eligibleDate = new Date();


      do you see this different from using the combination of dueDate and repeat ? if yes, how ?

      Secondly, I'm wondering why you have build a in memory version of the timer and message service. Is it only for easy testing ? Because when using the in memory database, it's also easy to run the tests. And in that case, the tests will use the real JobExecutor, so the test results will be much closer to what users will experience. And the JobExecutor will be better tested.

      I don't mind the having the memory job end timer sessions in the codebase. I'm just wondering what the motivation was/is.

        • 1. Re: timer update and questions
          pascal.verdage

          From what I understood, dueDate is the maximum date of execution, which means the Job has to be executed between now and dueDate. At least, this field was used this way. But the timer needs a minimum date of execution: the job is executed after eligibleDate.
          If this behavior is the one meant for dueDate, you should replace the field (or I do it and give you/Guillaume the patch since I'm the one who introduced this field).

          In memory versions are not just for testing. It is intended to provide versions of Bonita/Orchestra that run in memory even if the user has no db installed. For example if performances are really important but not crash recovery or to show the possibilities of these software.

          By the way, the main part of the JobExecutor will be used in both cases so it will be well tested.

          Regards,
          Pascal

          • 2. Re: timer update and questions
            tom.baeyens

             

            "pascal.verdage" wrote:
            From what I understood, dueDate is the maximum date of execution, which means the Job has to be executed between now and dueDate. At least, this field was used this way.


            if that is the case then it is a bug. the dueDate is the first time when the timer should be executed. after the first execution, if there is a repeat specified, the timer is rescheduled at dueDate+repeat.


            "pascal.verdage" wrote:
            If this behavior is the one meant for dueDate, you should replace the field (or I do it and give you/Guillaume the patch since I'm the one who introduced this field).


            don't you have already svn access ? if not, sign the contributor agreement and then i can give you access instantly.

            "pascal.verdage" wrote:
            In memory versions are not just for testing. It is intended to provide versions of Bonita/Orchestra that run in memory even if the user has no db installed. For example if performances are really important but not crash recovery or to show the possibilities of these software.


            As the consoles will get worked out, these will have a need for a lot of queries. Implementing those queries will be hard for the in memory version as you will have to iterate over the whole object graph and basically start programming your join queries in java.

            Definitely consider using the in memory database for that purpose.

            • 3. Re: timer update and questions
              pascal.verdage

               

              don't you have already svn access ? if not, sign the contributor agreement and then i can give you access instantly.

              No, I don't. I will discuss that problem with Miguel then fix that bug.

              Regards,
              Pascal

              • 4. Re: timer update and questions
                tom.baeyens

                 

                "pascal.verdage" wrote:
                ... fix that bug.


                LOL

                • 5. Re: timer update and questions
                  pascal.verdage

                  Hi,

                  I wonder if it is necessary to remove the dueDate of a job. It is not used but it is a feature providing task scheduling possibilities: if two jobs are available, the first to be executed is the one with the smaller dueDate.
                  Why removing an existing feature since it doesn't cost much to keep it?

                  Regards,
                  Pascal

                  • 6. Re: timer update and questions
                    aguizar

                    Isn't eligibleDate the field to be removed? dueDate should prevail in all jobs, even if they are not timers. If the job executor experiences overload and cannot execute jobs immediately, dueDate indicates the order in which jobs were requested. So keeping dueDate at the Job level is a necessary feature rather than a value add.

                    • 7. Re: timer update and questions
                      tom.baeyens

                      the plan was that Pascale is going to remove it and fix the dueDate to its originally intended behaviour.

                      Pascale, what is the status ?

                      Alejandro, are you volunteering to do it ? Pascale, Miguel, would you guys mind if Alejandro does update it ?

                      • 8. Re: timer update and questions
                        pascal.verdage

                        dueDate allows scheduling among the jobs by giving a (desired) maximum date of execution, but a job can be executed before this date. So this field is not suitable for a timer. This is why I added the field eligibleDate in the first place.

                        For a common job, dueDate should be set at Long.MAX_VALUE and eligibleDate to the current date. If the job needs to be executed quickly, we can set dueDate to a date in the near future. If the job is a timer, we have to set eligibleDate to the date the timer should be fired and dueDate to the same date if we want the timer to be executed as soon as possible.

                        So eligibleDate is necessary too. We can't put it in the Timer class because when we look for available jobs we would select all the timers, even if they shouldn't be fire yet.

                        Finally, if both field are required at the Job level, there would be no change to make.

                        Is that OK?

                        I didn't make any changes yet because I didn't know if the field dueDate would be removed.

                        BTW, Pascale is the feminine version of my name, which contains no 'e'.

                        Regards,
                        Pascal

                        • 9. Re: timer update and questions
                          tom.baeyens

                           

                          "pascal.verdage" wrote:
                          dueDate allows scheduling among the jobs by giving a (desired) maximum date of execution, but a job can be executed before this date. So this field is not suitable for a timer. This is why I added the field eligibleDate in the first place.
                          ...


                          As said before, this is a bug. DueDate should be fixed to become the first time that a job is being executed.

                          If dueDate is fixed that way, is there something else that you need the eligibleDate for ?

                          • 10. Re: timer update and questions
                            pascal.verdage

                            No, there isn't. Therefore I will modify dueDate and remove eligibleDate.

                            Regards,
                            Pascal

                            • 11. Re: timer update and questions
                              tom.baeyens

                              perfect. Thanks !

                              Alejandro, does that resolve your issue ? Are you waiting for this ? If yes, then you can always propose to Pascal to do it yourself.

                              • 12. Re: timer update and questions
                                pascal.verdage

                                The modifications are done. dueDate has its original expected behavior and eligibleDate has been removed.

                                Regards,
                                Pascal

                                • 13. Re: timer update and questions
                                  tom.baeyens

                                  perfect! thanks!

                                  • 14. Re: timer update and questions
                                    aguizar

                                    I wasn't waiting for it, but I saw it coming as a potential issue. Pascal was quicker, tough.