| Summary: | Quartz fails to persist a job detail, data truncation error occurs | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] JBoss BPMS Platform 6 | Reporter: | Radovan Synek <rsynek> | ||||||
| Component: | Business Central | Assignee: | Maciej Swiderski <mswiders> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Radovan Synek <rsynek> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.0.0 | CC: | kverlaen, rzhang | ||||||
| Target Milestone: | CR1 | ||||||||
| Target Release: | 6.0.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-08-06 20:13:43 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | 1049390 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
Created attachment 833603 [details]
error stacktrace from server log
It turned out that this issue is reproducible with those steps described above on MySql55 only, which has BLOB (data type of JOB_DATA column) limited to 64KB. On other production DBs similar data type is limited to at least 1 GB. However there is still the possibility this issue affects all DBs (if the JOB_DATA continue to grow over their BLOB limits). there was actually invalid handling of timer instances that were added to the job and thus causing every timer job to be bigger. While this makes sense in in memory scheduling it does not with db store as they are serialized to db any way loosing connection with origin. Has been replaced with post execution clean up logic. jbpm master: https://github.com/droolsjbpm/jbpm/commit/aa46474b47e5338d307a62960d455abc979ed930 6.0.x: https://github.com/droolsjbpm/jbpm/commit/8d74b37a5f1774f8310cdc802cf4ff0f824dc3ff Verified with BPMS-6.0.0.CR1 |
Created attachment 833602 [details] timer - process definition Description of problem: Having a jbpm cluster with two nodes (EAP 6.1.1 domain) and a load balancer (modcluster), processes with a timer (see the attached process definition) have been started via kie-remote REST client in a loop for five minutes. After let's say tens of seconds, probably every further attempt to start this process ended up with a following exception: org.quartz.JobPersistenceException: Couldn't store job: Data truncation: Data too long for column 'JOB_DATA'. Detailed stacktrace is also in an attachment. jbossqe-process-flood performance framework (maintained by jsvitak) has been used to generate the load. Version-Release number of selected component (if applicable): BPMS-6.0.0.ER5 Steps to Reproduce: 1. configure 2 node jbpm cluster on EAP 6.1.1. Although I used also load balance, I think it is not necessary to reproduce this issue. 2. deploy business central (configured with any production database) 3. Clone repository git://git.app.eng.bos.redhat.com/bpms-assets.git to your BPMS installation. 4. create an application account guest:guest with roles analyst,admin 5. Build&Deploy a project bpms-perf from the bpms-assets.git repo. 6. git clone git://git.app.eng.bos.redhat.com/jbossqe-process-flood.git cd jbossqe-process-flood/bpms-6.x ./execute_scenario.sh -Dscenario=Timer_kieREST