question about JobExecutor and Threads

[fengzhi]

hi guys,

Could you please give me some clue, what I need to read or learn to understand it ?

What does the JobExecutor make? I mean what is its using, why do we need it? I have taken a look in the code, but I don't understand and didn't find some document about it.

I am beginner in this area and sincere thanks you for sharing your experience.

regards,
Fengzhi

[jbarrez]

The JobExecutor is there to, like it's name says, execute Jobs.

Such a Job is for example a Timer (Timer is a subclass of Job).
If you look into the code of the JobExecutor, you will see that it queries the database for jobs whow duedate is passed, which means that this job should be executed. The JobExecutor will then delegate to the execution of the Job.

The JobExecutor which you can find in the distrubution is a normal Java thread, which is checking the database for available Jobs and executing them at regular time intervals (configurable in config)

[kukeltje]

or in the Enterprise version, it is based on EJB Timers

[tak2]

"jbarrez" wrote:

The JobExecutor which you can find in the distribution is a normal Java thread, which is checking the database for available Jobs and executing them at regular time intervals (configurable in config)

We are evaluating jBPM for the application on application server, not a stand alone java application, such as IBM WAS. I believe that WAS doesn't like to have application components creating unmanaged threads. Does someone run this class on WAS in production?

Instead I wrote MDB to execute Job table entries to utilized managed thread. Does jBPM have a plan to do the same approach?

[kukeltje]

Tak, look at my post... for JEE based solutions, jBPM uses ejb timers.......

[mnakahara]

hi,
I have a simple question.
Why is JEE based design using EJB timers so different from JobExecutor design?
It looks like JobExecutor polls the job table, fetch job entries, and execute them in a single thread
while ejb timer version creates timer thread per job entry.
This is because a performance improvement by concurrent execution using multiple threads?

I 'm thinking writing my own job execution mechanism worked in JEE environment which based on
JobExecutor implementation. It means only one ejb timer thread which polls, fetch and execute all avaliable jobs
is created in a JEE container.
What do you guys think this idea?

Regards,
Masa

[kukeltje]

I miss your point...

They are different because in JEE we can use something that is already there and is proven. For the other envs the jobexecutor is there

Making a new JEE jobexecutor seems illogical to me

[lblaauw]

Well,

Here is one usecase we are currently facing. We have lots and lots of timers spread around over many processinstances. The timers are pretty much only expring once every few months so are long outstanding timers.
We started of with EJB timers untill recently i discovered exactly this, that they are instantiating one thread per timer/job. In my specific scenario I am also currently investigating not using EJB timers as the jobScheduler because this causes way to much threads open in the application server and eventually performance will decrease dramatically dependant upon the resources of the machine...

Not really sure wich route we will take though...

As allways any ideas appreciated ;-)

Regards,
leo

"kukeltje" wrote:
I miss your point...

They are different because in JEE we can use something that is already there and is proven. For the other envs the jobexecutor is there

Making a new JEE jobexecutor seems illogical to me

[kukeltje]

I cannot imagine that each ejb timer is a thread that is kept for a long period if they are not running That does not sound as EE. Is that really so? What appserver are you running on.

[lblaauw]

well,

In debugging on jboss 4.2.2 GA it does seem that way unfortunately...

Leo

"kukeltje" wrote:
I cannot imagine that each ejb timer is a thread that is kept for a long period if they are not running That does not sound as EE. Is that really so? What appserver are you running on.

[kukeltje]

Just to be sure....
- I create 150 processes with 10 second intervals
- Each has a ejb based timer that will go off after (150*10)+100 seconds
- I end up with 150 threads each 'monitoring' one timer????

Hmmm.... a search on the internet showed that IBM is limiting this and indeed JBoss is not yet

Hmm.... this should be documented in the jBPM docs somewhere I think, since it is not real 'enterprisy'

[lblaauw]

Yup,

This suprised me a bit too.... yeah we have a very large amount of jbpm ejb timers that basically just sit there and expire every 6 weeks to three
months...

Still not really sure what route to take though allthough I suppose considering my long timeout value(weeks till months) the scheduler servlet, albeit single threaded should be ok for this usecase...

Greetz
Leo

"kukeltje" wrote:
Just to be sure....
- I create 150 processes with 10 second intervals
- Each has a ejb based timer that will go off after (150*10)+100 seconds
- I end up with 150 threads each 'monitoring' one timer????

Hmmm.... a search on the internet showed that IBM is limiting this and indeed JBoss is <a href="https://jira.jboss.org/jira/browse/EJBTHREE-1330">not yet</a>

Hmm.... this should be documented in the jBPM docs somewhere I think, since it is not real 'enterprisy'

[kukeltje]

The scheduler servlet van be configured to use multiple threads afaik... one 'polling' thread and multiple for executing the actions

[lblaauw]

Ronald,

Yeah I have implemented the executor without the servlet for now. Bit worried that it makes its own threads in a JEE app but it works for now. Maybe later on I will have some time in this project to make the jobexecutor use the JBoss managed workmanager threadpool as it really should in a JEE environment... ;-)

Leo

"kukeltje" wrote:
The scheduler servlet van be configured to use multiple threads afaik... one 'polling' thread and multiple for executing the actions

[salaboy21]

Interesting thread.. can someone create some wiki about this?
I will try to make a post in my blog about it..