Bug 834673

Marco Rietveld <marco.rietveld> 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?

Maciej Swiderski <swiderski.maciej> updated the status of jira JBPM-3688 to Open

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?

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.

Maciej Swiderski <swiderski.maciej> 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

So, Maciej, is this ported back to 5.2? can we change the status of the issue? or the assignee?

it is not yet backported, will take care of it

backported into 5.2.x branch

Maciej Swiderski <swiderski.maciej> updated the status of jira JBPM-3688 to Resolved

Verified in BRMS 5.3.1 ER3.

Based on the Doc Text information you have provided, I have updated the text for Release Notes purposes. Many thanks for this information. 

- Doug