How can we handle "Connection Refused Exception" Exception

I’m trying to handle exception on http-connector where I intentionally brought down my endpoint. Currently execution is failing with error( An error happened while submitting the task form : HTCL-02007 Unable to execute HTTP request) and I want to route the execution flow to User Task.

Something like this.
Can you please help here :slight_smile:

Hello, my friend! :smile:

Let’s summarize the step-by-step process:

1 - In your service task, create a “Connector output” as a String or expression to capture the status code with the value ${statusCode};

2 - In the same service task, configure an “execution listener - End” and set it as a script task.

3 - In the script of the execution listener, you will perform the desired treatment by either throwing a new org.camunda.bpm.engine.delegate.BpmnError(“yourBoundaryErrorEventName”) to propagate your instance to your error handling flow, or by throwing a new java.lang.Exception(response) to generate an incident in Camunda for manual treatment.

Sure, here’s a more detailed explanation: (I’m sorry, but as I don’t know your current level of knowledge, I took the liberty to provide a slightly more detailed explanation below in case you need it.)
I’ll give you a quick example of what can be done to handle this issue in your service task.

You will capture the response from your Service task, which could generate an error, and access its statusCode.

Then, you will configure an “Execution listener - End” to check if the statusCode is != 200 when your task is completed, and then handle it as desired.

To throw your instance into your error handling flow in Camunda, you should use “Throw new BpmnError,” as shown in the treatment below:

Alternatively, you can do it differently from my example by directly creating a response in Connector Output, only with statusCode using ${statusCode} and doing the same treatment later in the execution listener, as shown below:


I hope this helps.

William Robert Alves

Hi @WilliamR.Alves
Thank you for the details.

In my scenario, API is down (API is unreachable). So, as I checked it never reach connector output. It directly creating incident without any code. I want to avoid this.

Caused by: Connection refused: connect

Hello my friend!

I understand what you need, and it seems to me that there is no way to do this through the use of connectors.
Unfortunately, Niall himself communicated this in a 2021 post, but they are working to find a way to improve this. (Post in below!)

This happens because when the connector does not get any response from the server, it soon creates an incident, and thus it is not possible to do anything else in camunda except the retry manually.

So in this task I suggest you use JavaDelegate instead of http-connector, because in a delegate you can do the treatment even before generating the incident using a try / catch involving the REST call, and in case you are unable to make the call, throw Bpmn Error…

Hope this helps.

William Robert Alves

Thank you @WilliamR.Alves for detailed explanation.

I think replacing connector with java delegate in numerous places are time consuming.
Is there a way we can create our own connectors say http-connector-x?
If it is possible, I just need to update name in numerous places.
Sorry, asking too many follow-up questions :slight_smile:

Hi @camundabpmlearner,

the issues that @WilliamR.Alves links in his answer here can be solved with the external task pattern: External Tasks |

When you develop an external worker handling http requests in a generic way, you can control them much better than the internal thread in the Camunda engine using a JavaDelegate. You can handle timeouts here with the exception handling of the engine kicking in.

That’s also the way how connectors in Camunda 8 are built.

Hope this helps, Ingo


Hi @Ingo_Richtsmeier
I would like to know how can we automate this external task. In the given link External Tasks | I can see how external task works and how can we use rest api or java api to fetch & complete but I dont see how can we pick this external task as soon as task get created. Do we have to use execution listener?

Hello my dear @camundabpmlearner !

To define a job to be executed, in your worker / external task you will define a “topic name”, and inside your task in Camunda you will define it as “external task” and you will configure the topic name exactly as declared in your code Worker.

In the link below you can check better how you can do this:

I hope this helps.

William Robert Alves

Hi @camundabpmlearner

You can decrease the latency between creating and working on a task when you enable long polling in the client configuration. To do this, set the value for async-response-timeout to a higher value in milliseconds. And then it is safe to restrict the exponential backoff to a smaller amount than the 1 minute default or disable it at all.

Here is some background about long polling: External Tasks |

Hope this helps, Ingo

Hi @Ingo_Richtsmeier, @WilliamR.Alves
It does work if I keep camunda external task client in same camunda project but I if I try to keep it in another project (since in our organization we are not suppose to change camunda image) it’s not capturing the event. Is there a way it can work?

Attached sample client project for reference. Change extension to zip and extract.

camundaClient.bpmn (69.6 KB)
or reference.

Hi @camundabpmlearner,

it seems contradictory to me to call the same JVM via HTTP network calls. I haven’t tried it by myself.

But you can use the ExternalTaskService from Java as well: ExternalTaskService (Camunda Platform Javadocs 7.19.1-ee)

With this, you can create an ever running thread and call the ExternalTaskQuery once a while to get the new tasks, fetch-and-lock them and invoke your handler, before you complete the task. But with this approach, you are reimplementing the logic of the ExternalTaskClient framework.

I haven’t done this either, but it is possible as well.

Hope this helps, Ingo

Hi @camundabpmlearner
I am facing the same issue. If you got the solution please share.