Bug 1023162
| Summary: | Query pagination/result limiting in human task queries/commands | ||
|---|---|---|---|
| Product: | [Retired] JBoss BPMS Platform 6 | Reporter: | jbride <jbride> |
| Component: | jBPM Core | Assignee: | Shelly McGowan <smcgowan> |
| Status: | CLOSED EOL | QA Contact: | Radovan Synek <rsynek> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0.0 | CC: | jbride, kverlaen, lpetrovi, rrajasek, smcgowan |
| Target Milestone: | ER3 | ||
| Target Release: | 6.1.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-27 19:35:25 UTC | Type: | Enhancement |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
jbride@redhat.com
2013-10-24 18:55:15 UTC
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: https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.2.x/kie-internal/src/main/java/org/kie/internal/query/ParametrizedQueryBuilder.java#L100 https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.2.x/kie-internal/src/main/java/org/kie/internal/task/query/TaskQueryBuilder.java#L18 https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.2.x/kie-internal/src/main/java/org/kie/internal/task/api/InternalTaskService.java#L232 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: https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/test/java/org/jbpm/services/task/TaskQueryBuilderLocalTest.java#L451 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. 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? Thanks, Jiri Hello, 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! jeff 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. |