Hi Burr,

would be interesting why he thinks so, since I believe the Non-JMS-JobExecutor is stable as well (and we did some stress testing in one project). Only advantage of JMS is to maybe have existing JMS tooling available (to monitor the DLQ and so on) in my opinion.

Cheers

Bernd

Von: Burr Sutter [mailto:bsutter@redhat.com]
Gesendet: Donnerstag, 14. Mai 2009 01:44
An: Bernd Rücker
Cc: 'Tom Baeyens'; 'Len DiMaggio'; 'jBPM Dev List'; 'Mark Little'; 'John Graham'
Betreff: Re: AW: [jbpm-dev] Re: jBPM 4 limitations

Hey Bernd,

We have one user who believes the JMS-based JobExecutor is the only stable one on jBPM3. 

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

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@lists.jboss.org
[mailto:jbpm-dev-bounces@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