FWD » Core Development » Runtime Infrastructure

This task is about re-enabling support of FWD nio sockets implementation in Java 17. Recently customers were forced to disable such support in order to avoid non-deterministic hangs in the communication between server and client. Disabling them was a fix that shown no regressions (AFAIK) on Java 17. Important to note that Java 8 and nio sockets didn't show such issue or it was too scarce to be reported.

I suggest going with some very small examples out-side the FWD server-client architecture and attempt to debug the process (aka create 2 java projects which consumes the FWD implementation of nio sockets). Eventually, it should be stressed with millions of requests to check if it blocks at some point. If we can't reproduce this way, we will be forced to go into the FWD server/client architecture with plenty of logging to see what happens.

Lorian, please make an update on the work for #9414 in the current status. Also post the test-case that you built up for testing here. It can be used for reference on further attempts to do a small-scale server-client communication (for other tasks).

Alexandru Lungu wrote:

Lorian, please make an update on the work for #9414 in the current status. Also post the test-case that you built up for testing here. It can be used for reference on further attempts to do a small-scale server-client communication (for other tasks).

I tried to create a simple server-client java app that consumes the NIO implementation for p2j, but all my attempts failed. I managed to connect the client to the server socket but when i tried to put it in action with sending and receiving messages through p2j it was not working (or i did not fully understand how Queue and Writer , Reader threads work ?).
I thought it would work out of the box, but it was not the case here.

If this is high priority i will invest more time into trying to build up a test-case with the server-client architecture from p2j.

Summary of a discussion from a daily meeting:

• the default for the NIO sockets should be "off" - so disabled. This should be implemented as soon as a feedback from Greg is also provided.
• the support for the NIO socket should be reintegrated in the future if it is really beneficial for performance.
• unless there are good reasons to reintegrate NIO sockets, then this task can be rejected.

This should be implemented as soon as a feedback from Greg is also provided.

The feedback needed is about the proposed plan? Or is there other feedback needed?

In regard to the plan, I don't object so long as we have adequately compared the performance between NIO and non-NIO transports. I recall that we implemented NIO exactly for performance reasons, though to be fair I don't think we've compared them recently.

In other words, if NIO provides a measurable performance improvement, then we will retain NIO support.

The feedback needed is about the proposed plan? Or is there other feedback needed?

The plan was discussed in a daily meeting and the last point was "lets also get Greg's opinion on it". So yes, it was about a feedback on the plan.

Not sure if this is related but I've found an issue in com.goldencode.p2j.net.SSL.tryLock caused by #5388.
The change introduced a lock to protect shared data when copying it between buffers. The problem is that there is a very short timeout (100ms) set when lock is being acquired. In case the machine is under heavy load (or has CPU resources limited by docker) timeout occurs causing all communication to break. It mostly happens in the beginning of the session when SSL session keys are calculated.
I dont think any timeout should be there, but just to prevent deadlocks I will increase it to 10 seconds and test it with regression tests with very limited CPU resources. Maybe that fixes Java 17 NIO too.

In addition I've also found that NIO SSLHandshakeException may happen in Java 8 client when machine is under heavy load (e.g. docker -cpu 0.5 on startup)

javax.net.ssl.SSLHandshakeException: main:Handshake timed out.
    at com.goldencode.p2j.net.NIOSslSocket.<init>(NIOSslSocket.java:205)
    at com.goldencode.p2j.net.NetSocket$1.create(NetSocket.java:147)
    at com.goldencode.p2j.net.SessionManager.connect(SessionManager.java:1303)