Might be a silly suggestion but did you check adresses? Whether it is HTTP or https. At least we faced some issues because we added HTTP and not https. 

Hi @julian,

The address is HTTPS, which is correct as per the screenshot I have attached above. But still we are getting “STUCK THREAD ERROR”.

Thank You.

Regards,

Vivek NR.

You can always, get a thread dump and see whether it will give you more information/hint on where the issue is.

We also have the same problem and figured out that it happens when a Load balancer (SSL passthrough) is in place.

There seems to be a issue with HTTP sender when connecting to ssl endpoint and our finding is below.

• If there’s a WORK_TIMEOUT is not defined or value is > 30 (default connection timeout), I get error java.net.ConnectException: Connection timed out: connect
• If WORK_TIMEOUT < 30, get the error STUCK thread while executing native sender: 'HTTP_SENDER2' but there’s no stuck threads created!

weird thing is application message (might) successfully processed in a retry.

Has this been noticed by others?

We are in a serious situation due to this error since our integration worked fine in Dev environment where there’s no loadbalancer and in TEST it fails consistently.

Any feedback would be really appreciated.

App version: APP10 UPD6

BR,

Damith

=====Update about this issue:=======

• Connection timed out exception was found to be an issue with our network where it blocked the favicon and the the http request is failed due to that.I think IFS has nothing to do with this error but glad if there’s any http header or any other setting that we can use to avoid the errors due to static content download since the payload is already received.

but the second issue still remains and it happens when the request time exceeds WORK_TIMEOUT. I guess the error message is wrong and should be corrected. 

/Damith