AW: [jbpm-dev] Re: jBPM 4 limitations

[Tom Baeyens]

Burr Sutter wrote:
> Hey Bernd,
> 
> We have one user who believes the JMS-based JobExecutor is the only 
> stable one on jBPM3. 

we never have been able to reproduce that.

> Is the jBPM4 JobExecutor vastly better in architecture/design to make it 
> superior to the JMS-based solution?

only problem with JMS is building out the QA.  and building out the knowledge of the 
specific JMS configuration options that might impact the execution of jobs 
(redelivery, retries and so on)

that is why in jbpm 4 we opted to prioritize the job executor first.  after that we 
can prioritize JMS binding of asynchronous messaging.

apart from that, the jBPM 4 JobExecutor has been optimized significantly.  all job 
executor threads within one jBPM instance will not be competing any more for 
acquiring jobs.

and our first focus is to build out QA infrastructure so that we can reproduce and 
analyse *any* customer problem.

discuss if you don't think these are not the right priorities.

regards, tom.


> Burr
> 
> Bernd Rücker wrote:
>> Hi!
>>
>> A short comment on JMS and EJB Timers: Currently you can either use both
>> or none. And since EJB Timers fail to scale well, in the bigger projects I
>> know we always used the JobExecutor and skipped JMS and EJB Timers. And
>> the JobExecutor scales perfectly well, so this is not a problem in my
>> eyes. Maybe to not have the JMS Marketing sticker is not that good, but
>> this is for you to judge...
>>
>> Cheers
>> Bernd
>>
>> -----Ursprüngliche Nachricht-----
>> Von: jbpm-dev-bounces at lists.jboss.org
>> [mailto:jbpm-dev-bounces at lists.jboss.org] Im Auftrag von Tom Baeyens
>> Gesendet: Montag, 11. Mai 2009 11:04
>> An: Burr Sutter
>> Cc: Len DiMaggio; jBPM Dev List; Mark Little; John Graham
>> Betreff: [jbpm-dev] Re: jBPM 4 limitations
>>
>>   
>>>>>> * no async messaging through JMS
>>>>>>           
>>>> That will make some jBPM3 users unhappy. NTT feels this will add
>>>> scalability, especially in a cluster.
>>>>       
>>> Same here.  We have all functional components in place, but except for
>>>     
>> QA.  Setting that up requires productization resources which we don't
>> have.  So that work is now serialized and will have to be > > prioritized
>> after GA.
>>
>>   
>>>>> * no timer support through EJB Timer
>>>>>         
>>
>>
>>
>>   

-- 
regards, tom.