Bug 743419

Summary: async WorkingMemoryLogger
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Jeffrey Bride <jbride2001>
Component: jBPM 5Assignee: Kris Verlaenen <kverlaen>
Status: NEW --- QA Contact: Radovan Synek <rsynek>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: BRMS 5.3.0.GACC: atangrin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jeffrey Bride 2011-10-04 20:45:29 UTC 
currently, DML statements related to jbpm-bam functionality are made synchroneously within the scope of the same transaction as core jbpm5 functionality (processInstance, SessionInfo, WorkingItemInfo, task, etc)

load tests have revealed that, for instance, an invocation to 'startProcess' with jbpm-bam disabled returns about 2.5 - 3 times faster than when the jbpm-bam is enabled.

recommend that an 'AsyncWorkingMemoryLogger' be built such that jbpm-bam logging invocations be sent to a JMS provider rather than immediately writing to the jbpm-bam relational database.

Subsequently, a jbpm-bam MessageConsumer would also be created that consumes these jbpm-bam logging invocations in batch.  Once a configurable batch size is reached, the MessageConsumer would write to the jbpm-bam database using optimized SQL batch insert/update statements.

sorry, i don't yet have a working implementation of this.
Comment 1 Kris Verlaenen 2012-01-02 18:03:48 UTC 
(In reply to comment #0)
> load tests have revealed that, for instance, an invocation to 'startProcess'
> with jbpm-bam disabled returns about 2.5 - 3 times faster than when the
> jbpm-bam is enabled.

It would be useful to know if a call to startProcess with an additional load of sending like 6 JMS messages (in the same transaction) would be faster than just persisting the log events reusing the runtime persistence entity manager (which is just done in one commit, at the end of the transaction).

As it would be a pity if this in the end would be slower ;)
Comment 2 Marco Rietveld 2012-01-17 16:49:42 UTC 
Jeff, 

if we're doing this to improve performance, then it makes more sense to me not to use JMS/HornetQ. Why not just use "concurrent" java, so to speak? It does mean a lot more "gun" to "shoot yourself in the foot" with, but it will always be faster than the overhead time cost incurred by either the current implementation or JMS/HornetQ.
Comment 3 Kris Verlaenen 2012-02-28 23:17:44 UTC 
Marco, I think the concept of transaction might be critical here.  We only want these events to be stored (so the messages to be sent) when the transaction is committed successfully.  A transaction rollback should not save these events (not send the messages).  You could do this with JMS, not sure you could do the same with concurrent java.