need some pointers on an issue that we have where a boundary event attached to a service task not getting fired. Below is the property section of the boundary event.
public class XYZ extends Service implements Constants{
public Integer fun1(String formName,List Map1,Integer Id,String str) throws Exception {
// consume a service to create a request using org.apache.cxf.endpoint.Client from the stack it looks like there is an exception here which should bubble up and be caught at the top level.
}
}
So when the issue occurs we see that there is a callstack in the logs with “Caused by: java.net.SocketTimeoutException: Read timed out” and the process gets killed. However the behavior we need is that it logs the error and continues to execute with next steps.
in the code that I shared, there already is a try catch and its being thrown as a java exception. my question was why the boundary wouldn’t pick it and take the exception route?
Thanks Rob. I will try to write some sample code to test this.
Does this mean, we will have to use BPMNError all the time. Currently the exception handling is set up the way I described above. All seem to work except for the activity where its failing for external service (I see that the boundary event gets triggered for other tasks, but it’s not making any calls to external services).
I was trying to reproduce this issue and in my repro code the external exceptions are getting trapped by using java.lang.Throwable (not as BPMNError). I will try few different exceptions and let you know. is there any debugging setting that I can enable to get some more information (to enable more logging so we can check what is going on)?
I have the same problem: The exception boundary event is not triggered.
Is this true what @Webcyberrob says: It must be a BpmnError and not an other java exception?
Didn’t find this limitation in documentation. And if yes, why? Writing code wrapping every exception is really stupid.
Or is it perhaps because i configured a retry for this activity?
I haven’t configured an error ref for this boundary, so it should catch all.
Key takeways from my perspective is these kinds of exceptions are ultimately technical errors. The incident system tends to treat these technical errors for operator intervention via the console. If the treatment of the error is a business treatment, then the BPMN Error event makes this explicit.
However your code needs to differentiate the two treatments and thus potentially wrap a technical exception into a business exception.
There may be smarter ways to commoditize this - parse listerners to inject wrapper code, possibly an engine plugin approach…
@bmaehr you seem to be trying to mix concepts together and getting annoyed when opposite ends of the spectrum tools are conflicting when mixed together.
BPMN errors are Business Errors. They are part of the spec. They dont get triggered after 3 attempts, they get triggered as soon as the BPMN error is thrown. “Sign a Document… Oh! the signature is invalid, throw a bpmn error”
Incidents are for non-bpmn-errors. It is attempting multiple times because its a system error that could self-resolve.
If you need retry’s on your bpmn error, then use a looping logic on the gateway. or add a circuit breaker / loop counter to try N times and if error count reaches 3 then throw a BPMN error.