Issue #2014 - Unix Socket Client

[gregw]

For #2014 unix socket client. Replaces #2021 and #2024

[gregw]

Hmm IP validation still borked, but I'll take responsibility for merge as I can see all commits are signed off OK.

[gregw]

@olamy Some of the tests are failing for large content. The testRequestWithLargeResponseContent passes quickly every time for 2241024 sized responses, but timeouts every time for 2251024 responses?

investigating....

[gregw]

@olamy I think I have found a JNR bug that is causing our failures. When doing an asynchronous write that hits flow control, a write returns 0 bytes written, but it has consumed those bytes from the ByteBuffer anyway! So we don't resend them!

I can see this clearly in our logs, but will now try to reproduce with pure JNR.

[gregw]

There is definitely a JNR bug with flow controlled writes. I have opened jnr/jnr-unixsocket#50 and will now look to see if it is fixable.

[gregw]

The work around in this PR appears to work. I have submitted jnr/jnr-unixsocket#50 and PR jnr/jnr-unixsocket#51 to the JNR project to get a proper fix.

@sbordet we could merge in the mean time?

[gregw]

@sbordet I think we should go ahead and merge this (if it passes review) without waiting for a JNR fix. No action yet on the issue/PR I raised and the work around I have in this PR will fix problems we have already had with the server connector, also the fix becomes a noop if the bug is fixed and a new release put in place.

[olamy]

@gregw I cannot see unixsocket tests before the tests we just added recently in the branch.
Look at branch jetty-9.4.x, I can see classes UnixSocketClient, UnixSocketProxyServer or UnixSocketServer but they are not automatic unit test only manual tests.

[gregw]

@olamy oh right you are!
So explain to me again what is different about the jenkins environment that is preventing creating the unix socket? The latest attempt reports:

2017-12-28 13:54:39.196:WARN:oeju.UnixSocketConnector:main: cannot bind /opt/jenkins/workspace/.4.x-2014-unixsocket-client-3M7VMQ6ZFSCADTZSQI3RRJTIOHLHQAM6AKGGXC32525DJZYXWD3A/tests/test-http-client-transport/target/unix4834839090001667409.sock exists=false writable=false

So the file is for the expected target directory, which I assume is writable. It does not exist, which is also expected at this stage. The JNR code that throws this is just reported a failure from native code, so it is simply that the directory is for some reason not suitable for a unix-socket to be created?

What type of file system is it? is it encrypted? Let me alter the tests to try using a /tmp located file...

[olamy]

@gregw good catch on the file/directory not writable. I guess this should work in any directory writable. But let's try this /tmp and merge this (finally! :-) ).
I will have a look next week to understand why this directory doesn't exist neither writable (I will be away few days this week)

[joakime]

The new change results in ...

java.io.IOException: Invalid argument
	at jnr.unixsocket.UnixSocketChannel.doConnect(UnixSocketChannel.java:127)
	at jnr.unixsocket.UnixSocketChannel.connect(UnixSocketChannel.java:136)
	at jnr.unixsocket.UnixSocketChannel.open(UnixSocketChannel.java:68)
	at org.eclipse.jetty.unixsocket.client.HttpClientTransportOverUnixSockets.connect(HttpClientTransportOverUnixSockets.java:84)
	at org.eclipse.jetty.client.HttpClient$1.connect(HttpClient.java:605)

[gregw]

With the latest changes, I think that all the tests failing on jenkins are also failing locally. So there is still a problem with this PR that needs debugging.