Red Hat Bugzilla – Bug 1023162
Query pagination/result limiting in human task queries/commands
Last modified: 2018-01-30 23:33:38 EST
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:
- 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 ?
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.
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.
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?
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 ?
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.