Under what circumstances can Java's HttpURLConnection.connect() throw a ConnectionException?

Question

Hello! I'm currently working on a project that involves having two different back-end servers, both of which communicate via a RESTful API with another system for logging purposes. Both one of the back-end servers and the logging system were written using Dart while the other back-end server, the problematic one, was written in Java.

What I want to do: I'm attempting to make a POST request from the back-end servers (same content) to the other system.

What the issue is: While the Dart back-end server is having no issues communicating with the other system, I'm getting a ConnectionException on the Java one, stating:

ConnectException: Connection refused: connect

What I have tried: I've already looked up various possible causes for the exception occurring, none of which seem to be happening. Both the back-end server and the other system are running, the IP/port are correct (using the same URL for the other back-end server and working), shouldn't be a firewall issue, nor do I know how it could be, seeing as the Dart one connects just fine, and, for the same reason, the system is clearly listening for requests.

Where it gets weird: It doesn't seem to be related to the code I wrote for the Java back-end server, seeing as I took advantage of mockapi.io to create a quick... mock of my API to test if it would work there, and it did... Given this result and that it doesn't seem to be code related, at all, I decided to give in and ask here, praying anyone might have an idea of how this could be going wrong somewhere.

Answer 1

The information in your question is too general / high level for a proper diagnosis.

However, a "connection refused" error typically happens for one of the following reasons:

1. The client side is using the wrong details for the server endpoint; eg the wrong IP address or port, or the wrong hostname.
2. Someone not understanding how 127.0.0.1 / localhost work and using that by mistake.
3. Bind / DNS name resolution is messed up... and that is causing the client to use the wrong IP address.
4. The server end-point is not running; ie nothing is listening for the client's connection requests.

If there are proxies or loadbalancers in the picture, they can complicate things. It is also plausible that this is due to a.network misconfiguration, or a perversely configured firewall.

Most of these issues are not programming issues. Using mocks it not going to help.

If you are stumped, then some options are:

• Check server-side logs.
• Try opening connections in the client environment to the server; eg use wget / curl.
• Try doing some.network route tracing.
• Try doing some packet sniffing (at both ends!)
• Talk to "the.networking team"

Answer 2

Okay so, thank you Stephen C for the reply, it actually got me started on track to the solution .

First of all, due to the reply, I used Wireshark to go through the packets being sent and found the two most relevant ones, which I can't seem to post images of due to requiring reputation... Anyway, in the request frame, the information was sent correctly (omitting some data from it).

Line-based text data: text/plain (1 lines) {"fieldKey":omitted,"tagValue":omitted,"message":omitted,"tagKey":omitted,"fieldValue":"1","measurement":omitted}

Then, the reply.

Line-based text data: text/html (1 lines)

Invalid argument(s): The source must not be null

Invalid argument(s): The source must not be null

As you can see, the quoted text has a H1 type header being used. This is due to the text being encapsulated by html , body , ul and h1 tags, which made me think it couldn't be an error coming from a base language library, nor from one of my own exception handlers. What came to mind: InfluxDB.

I debugged the portion of code relative to sending the information to InfluxDB and, for whatever reason, there was no information reaching it. By checking the request's body, I would observe a simple {} , clearly not what was correctly sent, according to Wireshark. After trying countless ways to fix this, be it changing Content-Type headers or even how I would send the data, I decided to change libraries.

Initially, I was sending the requests using HttpURLConnection . Then, I tried HttpClient , which resulted in being able to actually see the message I found in Wireshark through the console, rather than an exception to handle. Finally, using Spring Boot's RestTemplate , it just worked. I don't exactly know why the other libraries would result in a packet being correctly sent and then arriving incorrectly but by using RestTemplate it just worked.

Thank you to everyone who took their time to read this and hopefully this helps others in the future in some way.