12 Replies Latest reply on Jan 31, 2008 2:52 AM by hazurek

    Another potential enhancement to jbpm

    argo516

      We like jbpm Timer support, however, it does not work with multiple hosts running against a single database scenario.

      By digging into JBPM code this appears to stem from the fact that SchedulerThread issues a simple query to get list of all due Timers and then executes them one by one (without locking anything). So it's possible that if two hosts fire SchedulerThread at the same time (this becomes increasingly more likely as the number of hosts grows) some Timers will be executed twice.

      I created a new scheduler service that takes care of this problem by properly locking and scanning JBPM_TIMERS table where only one box works on any given timer.

      Furthermore, instead of depending on a servlet to kick off the SchedulerThread I made it start automatically with jbpm runtime. This will allow jbpm timers to work outside of J2EE environment. However, I don't feel strongly about the way Timers are kicked off, so if people prefer to continue using the Servlet for compatibility reasons I am ok with that.

        • 1. Re: Another potential enhancement to jbpm
          camunda

          Hi "argo516",

          you can configure jbpm to use JMS for this in a multi host Java EE environment easily. You can look in the jbpm-enterprise source code, there you find an example for EJB 2, but it can be easily adopted to EJB 3 (because of compatibility issues, jBPM 3 is is tied to Java 1.4).

          Cheers
          Bernd

          • 2. Re: Another potential enhancement to jbpm
            argo516

            Jms is not an option for us since we don't use it in our application. I also think a fairly straightward out of the box distributed scanner (which is fairly simple to implement) is preferable to requiring jms for distributed timers to work.

            • 3. Re: Another potential enhancement to jbpm
              koen.aers

              I am afraid I don't understand your problem neither your solution. What do you mean with 'jBPM runtime'? jBPM is a library, there is no runtime unless you write an application that uses the library (such as the servlet that kicks off the SchedulerThread).
              Also, I don't understand your objections against JMS. To me this sounds like, 'using a JVM is no option because we don't use it, so we decided to write our own proprietary one'...
              Am I missing something?

              Regards,
              Koen

              • 4. Re: Another potential enhancement to jbpm
                argo516

                Using JMS requires JMS provider which not everybody wants to use. Especially if your application doesn't already use it. For example in our scenario (a distributed application) this would require setting up a central broker, something like ActiveMQ or WebSphere MQ, etc. Obviously, this is a lot of overhead for just getting timers to work.

                As for my proposal, there's nothing proprietary about it - it simply involves making changes to the SchedulerThread to use proper DB locking (for example using LockMode.UPGRADE_NOWAIT before executing the timer). This will prevent multiple hosts from picking up the same Timer.

                As to the runtime - I was simply referring to JBPM engine. Instead of relying on servlet.init() to kick start SchedulerServlet, which will only work in J2EE environments, I propose having jbpm itself start the thread. For example, when JbpmConfiguration is initialized it can start the thread. This is not a big deal for us, I was just making a comment since I'm sure there are people who do not run JBPM in J2EE environment.

                Hope this makes more sense.

                • 5. Re: Another potential enhancement to jbpm
                  tom.baeyens

                  afaik, the job executor threads first try to write their name in a job before they execute it. that update should be guarded with optimistic locking. if multiple threads try to do this at the same time, all but one should get an exception and they have to rollback. i think this requires READ_COMMITTED as hibernate optimistic locking requires isolation level READ_COMMITTED on the jdbc connections.

                  so please be more specific to the problem in the current code and what changes you want to apply and why.

                  the LockMode.UPGRADE_NOWAIT is not preferred as not all databases support LockMode.UPGRADE. that is why we opted for optimistic locking instead.

                  • 6. Re: Another potential enhancement to jbpm
                    kukeltje

                    Regardless of the locking issues...

                    The first E in JEE stands for enterprise. If people do not use JEE but want e.g. clustering, loadbalancing, whatever.. we (or anyone) should not try to build something around it. History learned me that it, in hindsight, is always to minimalistic and before you know it, there is this home grown not-called-jms-but-has-all-the-same-functionality-and-configuration.

                    In JSE, just make sure the schedulerthread runs on one node. All problems solved...

                    But that is my €0.014 (does anybody remember the time when it used to be €0.028?).

                    • 7. Re: Another potential enhancement to jbpm
                      kukeltje

                      hmmm... I was sure I typed a € sign and not € (has to be € because € does not work either, nor does & (had to use & and do not even use preview)

                      • 8. Re: Another potential enhancement to jbpm
                        camunda

                        I agree with Ronald. The feature sounds like Java EE, so why not using it...

                        • 9. Re: Another potential enhancement to jbpm
                          tom.baeyens

                          makes sense.

                          though if there is a problem, it would be nice to know what the root cause is.

                          • 10. Re: Another potential enhancement to jbpm
                            kukeltje

                            Sure, but some problems can be 'prevented' by just making sure they do not happen. Some do's and dont's for example around jee/jse use of jBPM functionality. We should not have to cope with all possible deployment.

                            E.g. the transaction issue reported by twicenightly ehh... twiceknightly is about using functionality as it was supposed to work but does not seam to.

                            • 11. Re: Another potential enhancement to jbpm
                              tom.baeyens

                               

                              Some do's and dont's for example around jee/jse use of jBPM functionality. We should not have to cope with all possible deployment.


                              i think that must be improved. and the new implementation of the environment should give us much more flexibility to resolve many of these inconvenience issues. on top of that, i would like to get more QA done on the most common combinations. that way we also should get more documentation of the various configurations. so people can start with an example configuration file that is exact or close to what they need

                              • 12. Re: Another potential enhancement to jbpm
                                hazurek

                                Tom, could you please look at JBPM-1072. There are my comments (from Alexey Kostylev). I think I've found a problem with optimistic locking - jobs are executed independently if locking was failed or not. Thank you.