Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support unix domain sockets in HttpClient #2014

Closed
gregw opened this issue Dec 5, 2017 · 8 comments
Closed

Support unix domain sockets in HttpClient #2014

gregw opened this issue Dec 5, 2017 · 8 comments
Labels
Enhancement Low Priority Sponsored This issue affects a user with a commercial support agreement
Milestone

Comments

@gregw
Copy link
Contributor

gregw commented Dec 5, 2017

extend the support for unix domain sockets to HttpClient

@gregw gregw added Enhancement Sponsored This issue affects a user with a commercial support agreement labels Dec 5, 2017
@gregw gregw added this to the 9.4.x milestone Dec 5, 2017
gregw added a commit that referenced this issue Dec 28, 2017
joakime added a commit that referenced this issue Jan 10, 2018
gregw added a commit that referenced this issue Jan 13, 2018
There are still problems with this impl (some client tests ignored) and there is still a work around for the JNR bug 50, however this impl is already much better than the unix socket support that is already in the release.  So will merge for now and put more effort in once there is a JNR fix.

* WIP add unix domain sockets support in HttpClient
* move unix socket client part to unix socket module #2014
* some cleanup #2014
* add missing headers #2014
* add TODO
* UnixSocket client refactor
* cleanup test and pom
* minor changes, use LOG.isDebugEnabled() before using debug method
* add UNIX SOCKET http client test with all other tests, push this to see what happen on Jenkins
* fix some unit tests
* fix more tests
* fix load test
* UnixSocket client
* Demonstrate JNR bug
* Worked around JNR bug 50
* close channel on client side as well
* more details in log
* log file path as well
* #2014 disable test per default as doesn't work on some environement
* Revert "#2014 disable test per default as doesn't work on some environement"
* test only on unix
* Allow test of specific transport(s)
* Move unix socket to /tmp
* move test socket to /tmp
* move test socket to /tmp
* ignore failing tests for now
* fix bean name and possible to use sys prop org.eclipse.jetty.http.client.AbstractTest.Transports with mvn cli
* test isBlank as surefire props is not null
* correctly create tmp file with @before
* do not delete file
* use /tmp as build directory doesn't seem to work within docker...
* do not delete sock file on client as it is own by the server
* file must not exist when binding unix socket
* #2014 fix license header
* network specific tests assumed
* Fixed to handle null selector keys
* add assume for tests that assume a network connector

Signed-off-by: olivier lamy <olamy@webtide.com>
Signed-off-by: Greg Wilkins <gregw@webtide.com>
gregw added a commit that referenced this issue Jan 31, 2018
Signed-off-by: Greg Wilkins <gregw@webtide.com>
@gregw
Copy link
Contributor Author

gregw commented Jan 31, 2018

The client still has regular unit test failures, so I have disabled the tests in the build for now and we need to review this implementation.

gregw added a commit that referenced this issue Jan 31, 2018
Signed-off-by: Greg Wilkins <gregw@webtide.com>
@olamy
Copy link
Member

olamy commented Jan 31, 2018

any logs?

@gregw
Copy link
Contributor Author

gregw commented Jan 31, 2018

I didn't capture them, but it produces verbose server and client dumps when it does fail, so it is a very long trace. I think this is currently a low priority, so let's no look at this until 9.4.9 is out.

@gregw
Copy link
Contributor Author

gregw commented Jan 31, 2018

Ah here is the start of a test failure:

Running org.eclipse.jetty.http.client.HttpClientLoadTest.testConcurrent[transport: UNIX_SOCKET]()
2018-01-31 11:06:34.191:INFO:oejs.Server:main: jetty-9.4.z-SNAPSHOT; built: unknown; git: unknown; jvm 1.8.0_152-b16
2018-01-31 11:06:34.474:INFO:oejs.AbstractConnector:main: Started UnixSocketConnector@1cd072a9{HTTP/1.1,[http/1.1]}{/tmp/unix2656145385526675422.sock}
2018-01-31 11:06:34.474:INFO:oejs.Server:main: Started @668ms
2018-01-31 11:06:34.497:INFO:oejus.SslContextFactory:main: x509=X509@ba8d91c(mykey,h=[],w=[]) for SslContextFactory@7364985f[provider=null,keyStore=file:///usr/local/home/gregw/src/jetty-9.4.x/tests/test-http-client-transport/src/test/resources/keystore.jks,trustStore=file:///usr/local/home/gregw/src/jetty-9.4.x/tests/test-http-client-transport/src/test/resources/truststore.jks]
2018-01-31 11:06:34.706:WARN:oejh.HttpParser:client-44: Illegal character 0xA in state=RESPONSE_VERSION for buffer DirectByteBuffer@23d2d3c1[p=8,l=16384,c=16384,r=16376]={\r\n71A4\r\n<<<\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00>>>}
org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: bad response on HttpConnectionOverHTTP@16b972ac(l:null <-> r:null,closed=false)=>HttpChannelOverHTTP@53bbee1f(exchange=HttpExchange@49ca7582 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@4720824d(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@6222f949{s=START}],recv=HttpReceiverOverHTTP@3f53cbb3(rsp=IDLE,failure=null)[HttpParser{s=CLOSE,0 of -1}]]<-UnixSocketEndPoint@33941150{null<->null,OPEN,fill=-,flush=-,to=1/0}{io=0/0,kio=0,kro=1}->HttpConnectionOverHTTP@16b972ac(l:null <-> r:null,closed=false)=>HttpChannelOverHTTP@53bbee1f(exchange=HttpExchange@49ca7582 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@4720824d(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@6222f949{s=START}],recv=HttpReceiverOverHTTP@3f53cbb3(rsp=IDLE,failure=null)[HttpParser{s=CLOSE,0 of -1}]]
	at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.badMessage(HttpReceiverOverHTTP.java:334)
	at org.eclipse.jetty.http.HttpParser.badMessage(HttpParser.java:1528)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1510)
	at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:173)
	at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:134)
	at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:72)
	at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133)
	at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:155)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:242)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:384)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$1.run(QueuedThreadPool.java:626)
	at java.lang.Thread.run(Thread.java:748)

@stale
Copy link

stale bot commented Nov 20, 2019

This issue has been automatically marked as stale because it has been a full year without activit. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Stale For auto-closed stale issues and pull requests label Nov 20, 2019
@gregw gregw removed the Stale For auto-closed stale issues and pull requests label Nov 20, 2019
@stale
Copy link

stale bot commented Nov 25, 2020

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Stale For auto-closed stale issues and pull requests label Nov 25, 2020
@sbordet
Copy link
Contributor

sbordet commented Nov 25, 2020

I think we should wait for https://openjdk.java.net/jeps/380.

@stale stale bot removed the Stale For auto-closed stale issues and pull requests label Nov 25, 2020
@sbordet
Copy link
Contributor

sbordet commented Jun 15, 2021

Closed in favor of #6043.

@sbordet sbordet closed this as completed Jun 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Low Priority Sponsored This issue affects a user with a commercial support agreement
Projects
None yet
Development

No branches or pull requests

3 participants