Bug 834673 - JBPM-3688: Human Task dying issues
JBPM-3688: Human Task dying issues
Status: VERIFIED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5 (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Maciej Swiderski
Marek Baluch
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-22 14:25 EDT by Lukáš Petrovický
Modified: 2016-09-20 01:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In instances where an incorrect request was issued to the human task server, the incorrect request would result in a runtime exception that caused the human task server to die, which meant no more requests could be processed. This has been resolved by ensuring the human task server is not affected by runtime exceptions, and the process requests continue in the human task server.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBPM-3688 Major Resolved Human Task dying issues 2015-12-04 09:57 EST

  None (edit)
Description Lukáš Petrovický 2012-06-22 14:25:26 EDT
Please backport to BRMS 5.3 branch after we've got the proper ACKs.
Comment 1 JBoss JIRA Server 2012-07-03 04:16:24 EDT
Marco Rietveld <marco.rietveld@redhat.com> made a comment on jira JBPM-3688

Maciej, I thought I saw a commit which fixed the incorrect command name/class -- did you fix that already? 

Also, re return runtime exceptions -- well, 2 things: 

# log them, and 
# make sure that if the thread really does have to die, that it dies as follows: 
a. in a way that leaves some sort of state behind, so that it's possible to "restart" the thread or have the work it was doing be recovered. 
b. in a controlled way, instead of just dying because of an exception. 

2a. might be overengineering, any thoughts on that?
Comment 2 JBoss JIRA Server 2012-07-03 05:18:35 EDT
Maciej Swiderski <swiderski.maciej@gmail.com> updated the status of jira JBPM-3688 to Open
Comment 3 Maciej Swiderski 2012-07-03 05:26:16 EDT
Correct, it was fixed on master with this commit: https://github.com/droolsjbpm/jbpm/commit/b584699cd7afc7338528cd774df3fd5617a3b729

In general, incorrect command name was fixed for getTaskByWorkItemId so no more CCE is thrown in case of server side exception.

Regarding threads management, there are few improvements:
- server side - thread should "die" only if consumer attached to it is no longer active - so the change in the thread loop to continue as long as consumer is not closed, besides that all exceptions are logged and nothing is rethrown

- client side - for receiver side, it relies on the same rule as server - as long as consumer is active the thread will be active as well, in addition it has capability to reconnect in case object close exception is thrown by hornetq for both sender and receiver side, moreover when sending operation will be retried if reconnect succeeds

Is this what you had in mind?
Comment 4 Marco Rietveld 2012-07-03 06:07:28 EDT
After talking with Maciej, I realized that part of the problem is that there are a couple places in the persistence logic where

1. There's not enough input checking and/or
2. The query logic expects 1 result _or_ a list of results, but gets the opposite from what it expected. Unfortunately, in this case, the Java (JPA) code isn't built to handle this and it ends in exceptions (see JBPM-3688 for an example, actually). 

This means that we need to: 

A. add more input checking to the persistence methods -- although I'm not sure how to handle situations in which the input is "wrong". 
B. Add more exception handling to the JPA query Java code so that unexpected results to a query don't crash a thread. 

To some extent, these principles apply to all of the HT code -- although I think the rest of the code is a lot more robust than this particular part.
Comment 5 JBoss JIRA Server 2012-08-15 14:20:04 EDT
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3688

one more commit to avoid infinite retries in case of broken connection to task server: https://github.com/droolsjbpm/jbpm/commit/e302939576aa4f9fc6c0695d0824c8948a9ca1b1
Comment 6 Mauricio Salatino 2012-08-21 18:00:34 EDT
So, Maciej, is this ported back to 5.2? can we change the status of the issue? or the assignee?
Comment 7 Maciej Swiderski 2012-08-22 04:35:23 EDT
it is not yet backported, will take care of it
Comment 8 Maciej Swiderski 2012-08-23 11:34:24 EDT
backported into 5.2.x branch
Comment 9 JBoss JIRA Server 2012-09-28 09:05:59 EDT
Maciej Swiderski <swiderski.maciej@gmail.com> updated the status of jira JBPM-3688 to Resolved
Comment 10 Jiri Svitak 2012-10-11 05:56:54 EDT
Verified in BRMS 5.3.1 ER3.
Comment 11 Douglas Hoffman 2012-10-21 22:57:52 EDT
Based on the Doc Text information you have provided, I have updated the text for Release Notes purposes. Many thanks for this information. 

- Doug

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