One-way traffic.

Maybe a firewall rule on the non-receiving end has been (de)activated?

Good thought.
Checked all that I think.

check with netstat to see if the connection gets established. use "netstat -an" and look for Established. if you see "SYN" then the connection is not working and you should check your firewalls, both ends

Wireshark to capture network traffic on each system.

Does ping work from each system to the other.
Check the windows firewall as well.

Thnx.

This is netstat -an result :

Machine 1 : ( Machine 1 has IP address 192.168.1.115 )
===========================================
  Proto  Local Address          Foreign Address        State

  TCP    0.0.0.0:40000          0.0.0.0:0                            LISTENING
  TCP    0.0.0.0:40001          0.0.0.0:0                            LISTENING

  TCP    192.168.1.115:49490    192.168.1.71:40000     ESTABLISHED
  TCP    192.168.1.115:49491    192.168.1.71:40001     ESTABLISHED


Machine 2 : ( Machine 2 has IP address 192.168.1.71 )
===========================================
 Proto  Local Address          Foreign Address        State

  TCP    0.0.0.0:40000                0.0.0.0:0                               LISTENING
  TCP    0.0.0.0:40001                0.0.0.0:0                             LISTENING

  TCP    192.168.1.71:40000    192.168.1.115:49490         ESTABLISHED
  TCP    192.168.1.71:40001    192.168.1.115:49491         ESTABLISHED

I'm about to run Wireshark after updating it. Pings work in both directions.

Also, my code has its own connection monitor thread, and that is also satisfied that both machines can see each other.

You are showing the same set of connections

Without knowing how your app is supposed to work.


192.168.1.115 is the one that cab send since the Java app is bonnected to the remote side, the Java app on the other system is it running?

Is it a client-server
Are the IP of the other hard coded or they are determined based on DNS hostname?

What if anything triggers the connection from 192.168.1.71 to the server component o. 192.168.1.115?

.115 can receive only.

The two machines are connected for sure, over a Java socket. Both have serversockets listening for the other to connect, so it doesn't matter which one initiates the connection.

The IPs are static, so they are always the same.

As I said earlier, they both could send and receive, but then for some reason only .71 can send, and .115 able to receive. They seem to have become cross-wired somehow.

I guess it is an issue of which is a client and which is the server.

Commonly the server is defined Das the one that is listening for incoming connection from clients.

In this formulatio. The 1.115 is the client connecting to 1.71

Ref your netstat info.

If you are on the 1.71 system, can you telnet to 1.115 40000 or 40001?
If you can, that answers the first part, network path.

The second question. What triggers the initiation of the connection. Of a Java app running on 1.71 as the client that connects to 1.115 40000/40001.

Compare what is running 1.115 to see which process is connecting
to 1.71

lsof -i:49490
Based on the connection listing on 1.71.

Then see why the same process is not running o. 1.71

Another possibility: blocked thread(s). Check that a thread you need to send/receive on is not blocked in such a way that it's unusable. Thread dump

<<Thread dump>>

Right. As it's a longish dump, is there anything I should be looking for in particular, just to cut down on the clutter in this Q ?

One thing you could do is to get a reference to, and name the thread in question. That should appear in the dump

Another thing that might have happened is a swallowed exception, crashing the thread and leaving no trace

Careful use of logging should in theory leave you in a position where you know at all times what the execution flow is and whether it's meeting expectation

What is the setup.
Is there one thing that runs as a service listening for incoming connection.
And is there a separate application started by a user that initiates the connection to the other

or is the application is a client/server type the server portion listens for incoming connection while the client portion connects to the other server?

The first Thing in either scenario that I would do is to exclude a change to the firewall. IP confirm of the pair IPA is what it needs to be and IPB what it needs to be.
the system that currently has not inbound connections to the server ports 40000/40001
That would be the first thing to check, can you establish a TCP socket connection to either port.
If you can not, checking the windows firewall on that system to make sure inbound rules were not altered, or impacted by an inadvertent network classification change....

If not mistaken, a suggestion was to look at the netstat -an and whether there are outbound connection to port 4000/40001 are seen as Syn_sent event.

Presumably there was no software update release.

netstat -an output already posted above. Firewalls are not the issue. Nor is TCP as such - both peers are connected ok. Either one can act as the session server.

Previously are the two suppose to.open a connection. To the other.

What happens if you restart the service/application. On the 71 side does it initiate a co neutron to 115?

The understanding, knowledge of how the two hosts are supposed to interact would.provide the next steps to get to why the interactions are not working.

Actually, it's going to be very unlikely to dig any deeper with this one, and I'm going to have to fundamentally refactor the code rather than spend time de-bugging it (if it even is a 'bug' at all). My gut feeling is that there is something going on with some difference between Windows 8.1 and Windows 11 and the probably greater stringency of Java 20. But I'm not going to wrestle with that
 as I can't spare the time, and will make a fresh run at it with better graphing.

Grateful for all suggestions that were made. Thanks.

11 has a more stringent Certificate enforcement.

If you recreating/recompiling the app, build into the new iteration logging and error reporting.