Bug 1023162 - Query pagination/result limiting in human task queries/commands
Query pagination/result limiting in human task queries/commands
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
medium Severity low
: ER3
: 6.1.0
Assigned To: Shelly McGowan
Radovan Synek
Depends On:
  Show dependency treegraph
Reported: 2013-10-24 14:55 EDT by jbride@redhat.com
Modified: 2018-01-30 23:33 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Enhancement
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jbride@redhat.com 2013-10-24 14:55:15 EDT
  Seems that org.kie.services.remote.util.Paginator should not be needed.
Instead, it seems that raw database pagination should be utilized via JDBC and hibernate as per functionality provided in org.jbpm.shared.services.impl.JbpmServicesPersistenceManagerImpl (line 525 ).

But to take advantage raw database pagination, it seems that there are some core jbpm human task changes to be made:

1) org.jbpm.services.task.identity.UserGroupTaskQueryServiceDecorator
   - only one function currently allows for pagination parameters as part of the query .   Seems that all of the functions should.

2)  CommandPattern classes do not accept pagination parameters.  ie:  GetTaskAssignedAsPotentialOwnerCommand .

once these jbpm human task issues are addressed, it seems that the execution server can delegate pagination to the database, correct ?

thanks!   jeff
Comment 3 Marco Rietveld 2014-11-14 10:47:22 EST
CLARIFICATION: This is a new feature request, and as such has been fixed in the community 6.2/product 6.1 release, NOT the 6.0 releases. 

Hi Jeff, 

With the new Rich Query features (https://github.com/mrietveld/droolsjbpm-integration/wiki/Rest-Query-API), this has also been covered in the backend logic that supports this operation: 


At the moment, the .taskQuery(String userId) operation is part of the InternalTaskService interface and not a "public" operation, but I'm hoping to make it part of the API in the next release. I'm pretty sure that this pattern will already replace all of the (Internal)TaskService.getX operations and the Audit(Log)Service.find* operations, where a similar operation is also available.  

For examples of it's usage, see the tests here: 


Some of the reasons that it's still internal is that
1. It's new, we want to make sure the kinks are out before making it public
2. I need to write some docs for it, obviously.. :/ 

Let me know if you have questions.
Comment 4 Jiri Svitak 2015-02-03 09:05:51 EST
Hello Jeff,

What do you think about the Marco's comment, does it address your request?

Can you please describe how this issue should be tested? Do you have a reproducer/test for this issue?

Comment 5 jbride@redhat.com 2015-02-03 11:01:34 EST
  Thank you Marco!

  In regards to QA ... i do not have a test case handy, sorry.
  My recommendation is to build a test script that invokes these modified human task query APIs using a variable number of human tasks persisted in a postgresql and/or mysql database.  ie:  test with 1 task persisted in the jbpm database . Then test with 100 tasks --> 1K --> 10K ---> 100K .   How much is the performance degredation between tests ?

thanks again!
Comment 6 Tomas Livora 2015-03-24 11:55:16 EDT
I have tested it the way Jeffrey proposed in comment 5. I prepared 100, 1000, 5000, 10000 tasks and always tried to get only 100 of them. If I get the first 100 tasks there is practically no performance degradation between the queries. If I get 100 tasks from the middle, there is measurable degradation. However, I think this is caused by the database system itself. If there was something wrong with the task pagination, it would also influence the performance of getting the first 100 tasks. So I assume this BZ is resolved and I am marking it as VERIFIED on BPMS 6.1.0 ER6.

Note You need to log in before you can comment on or make changes to this bug.