8 Replies Latest reply on May 28, 2013 5:40 AM by swiderski.maciej

    JEE + jBPM + threads

    sergey.sazonov

      Hi, I am new to jBPM and trying to integrate it with my JEE application. Basically I have a servlet handling all incoming requests and proxying them to an EJB stateless bean that contains all jBPM stuff. So if I call ksession.startProcess and my process has timer nodes then control returns immediately from this method and a new thread is created. This thread waits for delay specified for my timer node and then shuts down.

      1. Could you please help me and explain how I can avoid additional thread creation.

      2. And maybe you can give me any advices for best practice in integration JBPM5 and JEE for long running processes with global and timer events.

       

      Thanks.

        • 1. Re: JEE + jBPM + threads
          melc

          Hi,

          Whenever the process reaches a wait state, such as a timer, it will return to the point where it was called.

           

          If you want the code to block then you can write any custom java code (aka workitem) even use a script task that does some kind of job or simply waits for some time. This is bad practice if you use a single persistent session, since the main thread will get blocked and not be responding to any requests. If you use multiple sessions e.g. session per request, i guess it will be fine if you don't mind about persistence, since blocking tasks do not get persisted, only on a wait state persistence takes place. Can you please explain why the thread creation worries you?

           

          Regarding issue 2 if you need to persist state then you should use persistent session and a common approach, as shown by the jbpm-gwt-console implementation, is to have a singleton session. So in your case you could use a singleton ejb initializing the session and providing it to the ejbs with jbpm related logic. If you need to scale, you may later on add some kind of a pool of sessions in your singleton bean.

          • 2. Re: JEE + jBPM + threads
            sergey.sazonov

            Thanks, Chris.

             

            I think I should be more descriptive from the beggining. I have really huge amount of long running persistent processes (up to 100 000 simultaneously). They actually don't do any work but wait for external events and may contain timers. Each process may create several subprocesses, so I use one KnowledgeSession per process with all children to avoid mixing of contexts. According to "jPBM5 developers guide" my algorithm for jBPM processing consists of several standart steps:

            1. Create process.

            2. Run.

            3. Dispose.

            4. If some external event happens then load a process.

            5. Run.

            6. Dispose.

             

            If I have a timer node in my process, I don't want to keep a process instance in memory and wait for an additional timer thread (and don't want to block main thread as well), I create EJB timer with an equal time period and dispose a session. And if my EJB timer is triggered, I just load a linked process. So I don't have to reserve many server resources to keep this army of jBPM process instances.

             

            I don't keep any state at runtime (only KnowledgeBase is shared), each call to jBPM code occurs in stateless EJB bean to gain better scalability.

             

            p.s. Besides that each jBPM thread doesn't know anything about servlet container's context and now I don't know any legal and easy way to change that.

            • 3. Re: JEE + jBPM + threads
              sergey.sazonov

              I really don't know if my approach to jBPM5 and JEE is good. Could you give me any advice for my previous message? Thanks.

              • 4. Re: JEE + jBPM + threads
                swiderski.maciej

                First of all process instances are not kept in memory if they are not actually executed. Meaning when process instance is in wait state (e.g. human task, timer, etc) process instance will be removed from the ksession and stored only in db. Whenever it's needed it will be loaded and executed - for example when timer fires it will load the process instance and execute it.

                Although in jbpm 5.x timers are managed on session level so they will be fired as long as session is active. If you dispose session then timer will not fire at the right time but when you load the session all overdue timers will be fired then.

                Moreover each session will have a dedicated ThreadPool for timers with single thread in it by default.

                 

                Looking at what you have implemented (ejb timers) I don't see a point of having timers in the process if you are not using them. Since you manage timer on your own you could use only signal events instead, so when ejb timer fires you send signal to process instance to continue processing.

                 

                With version 6 it will be possible to have more advanced timers and session management where you could externalize timer management for example to quartz (out of the box support).

                 

                HTH

                1 of 1 people found this helpful
                • 5. Re: JEE + jBPM + threads
                  sergey.sazonov

                  Thanks. Could you please explain the timers activation algorithm after loading a session from a safe state? Do they fire in the main thread?

                   

                  Just found that if I have a boundary timer event in an embedded subprocess it doesn't fire when I load a session (after disposing) and its period is exceeded. Is it a bug or I have to manually send some event to my session like "timerTriggered"?

                  • 6. Re: JEE + jBPM + threads
                    swiderski.maciej

                    Sergey Sazonov wrote:

                     

                    Thanks. Could you please explain the timers activation algorithm after loading a session from a safe state? Do they fire in the main thread?

                    it will execute by dedicated thread - as descirbed above, timer service will have it's own thread pool with size 1, so that thread will be used to fire the overdue timer. If there are more than one then they will be executed in sequence since there is single thread in the pool.

                     

                     

                    Sergey Sazonov wrote:

                     

                    Just found that if I have a boundary timer event in an embedded subprocess it doesn't fire when I load a session (after disposing) and its period is exceeded. Is it a bug or I have to manually send some event to my session like "timerTriggered"?

                    you might run into this bug, there should not be any other work needed from application side to trigger timers.

                     

                    HTH

                    • 7. Re: JEE + jBPM + threads
                      sergey.sazonov

                      Thanks again.

                       

                      I chose the way with signal events instead of timers. If I need a timer I just create an event "timerEvent_1000" where 1000 is the interval of the timer. In ProcessEventListener I catch all these event difinitions and create EJB timers. When an EJB timer is triggered I send "timerEvent_1000" to my process. So I got what I need. One thread for one call to jBPM and unlimited container managed threads.

                       

                      Also I could successfully run jBPM 5 with GlassFish 3 and EclipseLink. If anyone is intrested in that I can write down the details.

                      • 8. Re: JEE + jBPM + threads
                        swiderski.maciej

                        Sergey Sazonov wrote:

                         

                        Also I could successfully run jBPM 5 with GlassFish 3 and EclipseLink. If anyone is intrested in that I can write down the details.

                        That would be more than welcome so please make a blog post about it I am sure that many people will appreciate it!

                         

                        Cheers