Sorry for the checkstyle issues, tested this as an anonymus class before moving to an inner class and cleaning it up properly :/

@derklaro no worries, and thanks for spotting the issue and providing a fix!

Do you think this is something testable? Would really love to have it covered, to avoid regressions in the future in this critical piece of code 👍

I'm not sure if this can be tested actually as it's requiring java 16+ to run while all builds can only run on java 8 🤔

@derklaro ah, I didn't notice that this code is only for UnixSocket that requires Java 16. But then I am confused - you said that it is fixed in Java 13, and the minimum Java requirement for it to run is Java 16. Why do we need a fix then?

I was wrong there. They resolved other issues by replacing it with locks but not the synchronize issue. The point there is that other channels might not allow concurrent reading and writing which may lead to problems...

To bring everything in order again as my comment is a bit messed up. JDK-4774871 (Channels.newInputStream() and newOutputStream() synchronize too much) describes the issue I was oberserving with the channel input and output stream methods previously. JDK-4509080 (Streams inhibit concurrent reading & writing) is explecitly talking about the Socket#write and Socket#read methods which are blocking as well, comment on that issue: "The socket adaptors were partly re-implemented as part of JDK-8222774 and so are no longer constrained to use the blockingLock. As a result, concurrent reading and writing with the socket adpator is possible", which does not mean that Channels.newInputStream and Channels.newOutputStream are no longer blocking as they will still block on the lock provided by SelectableByteChannel.

To sum it up: Socket#write and Socket#read are no longer blocking while the Channels.new Input/Output Stream methods are still using the blocking lock (which is an expected behaviour).

So there are 2 possibilities here: Either we re-implement our own input and output stream, or (what i did) implement one of them on our own. (OutputStream is the better choice imo as it isn't as much code as the InputStream) to prevent the concurrent synchronize on the blocking lock.

Hope this explains everything better now! :)

Hey, are there any updates on this? I'm facing the same issue 😢

Hi @derklaro,

I finally got a chance to dive deeper into this issue. Do I understand correctly that the actual problem is in Channels#writeFully that uses sc.blockingLock() in case of a SelectableChannel?

If so, perhaps a much simpler solution would be to make passed WritableByteChannel not implement SelectableChannel so that it won't be synchronized on sc.blockingLock()?

Hey,

You mean by creating a special implementation of WriteableByteChannel which just passes all method calls down to the actual channel? Thats sound easier to me as well 😂

@derklaro yep, that's the idea :) To reuse as much JDK's code as possible. Something like:

        class PlainWritableByteChannel implements WritableByteChannel {

            @Override
            public int write(ByteBuffer src) throws IOException {
                return socketChannel.write(src);
            }

            @Override
            public boolean isOpen() {
                return socketChannel.isOpen();
            }

            @Override
            public void close() throws IOException {
                socketChannel.close();
            }
        }

        return Channels.newOutputStream(new PlainWritableByteChannel());

Also... any chance we can unit test this?

The only way i see is to write a test which only runs when we test on Java 16+ or above, which kinda breaks the purpose for a test...

@derklaro okay, I tried playing with implementing it with JDK8 only classes but the test becomes a bit too involved.

Also, AttachContainerCmdIT#attachContainerWithStdin will catch this (and also confirms that the PR fixes the issue), so it should be a matter of adding JDK16+ testing to the CI matrix (can/should be done separately), so I am fine with proceeding without a test.

As a result, concurrent reading and writing with the socket adpator is possible", which does not mean that Channels.newInputStream and Channels.newOutputStream are no longer blocking as they will still block on the lock provided by SelectableByteChannel.

Let me double check the implications of removing the synchronization with the JDK community because it must be there for a reason, and if it's okay for us to not have it, I will be happy to finally merge this 🎉

Sounds good to me 👍

FTR I just added Java 17 to the CI matrix. In fact, this PR should fix it because currently the main branch is broken and fails on that "attach" test :D

Okay... after not hearing any concerns from anyone, I am going to YOLO it 😂

I can confirm that it fixed the test, and other tests are passing as well, so I see no reasons why we shouldn't be doing this.