[Help wanted] io.grpc.okhttp.OkHttpClientTransportTest fails in Mac and GitHub Actions
See original GitHub issueIn master, I cannot build :grpc-okhttp module because OkHttpClientTransportTest fails in my Mac (Mac OS 11.2.3) and GitHub Actions (link).
suztomo-macbookpro44% git log -1
commit d4fa0ecc07495097453b0a2848765f076b9e714c (HEAD -> master, origin/master, origin/HEAD)
Author: Chengyuan Zhang <chengyuanzhang@google.com>
Date: Mon Apr 12 14:55:31 2021 -0700
...(omit)...
suztomo-macbookpro44% cat gradle.properties
skipCodegen=true
skipAndroid=true
suztomo-macbookpro44% ./gradlew cleanTest :grpc-okhttp:test --tests=io.grpc.okhttp.OkHttpClientTransportTest
*** Skipping the build of codegen and compilation of proto files because skipCodegen=true
* Skipping the build of Android projects because skipAndroid=true
> Task :grpc-okhttp:test
io.grpc.okhttp.OkHttpClientTransportTest > proxy_200 FAILED
org.junit.runners.model.TestTimedOutException: test timed out after 10 seconds
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
at java.net.ServerSocket.implAccept(ServerSocket.java:545)
at java.net.ServerSocket.accept(ServerSocket.java:513)
at io.grpc.okhttp.OkHttpClientTransportTest.proxy_200(OkHttpClientTransportTest.java:1876)
io.grpc.okhttp.OkHttpClientTransportTest > proxy_500 FAILED
org.junit.runners.model.TestTimedOutException: test timed out after 10 seconds
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
at java.net.ServerSocket.implAccept(ServerSocket.java:545)
at java.net.ServerSocket.accept(ServerSocket.java:513)
at io.grpc.okhttp.OkHttpClientTransportTest.proxy_500(OkHttpClientTransportTest.java:1933)
io.grpc.okhttp.OkHttpClientTransportTest > proxy_immediateServerClose FAILED
org.junit.runners.model.TestTimedOutException: test timed out after 10 seconds
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
at java.net.ServerSocket.implAccept(ServerSocket.java:545)
at java.net.ServerSocket.accept(ServerSocket.java:513)
at io.grpc.okhttp.OkHttpClientTransportTest.proxy_immediateServerClose(OkHttpClientTransportTest.java:1989)
68 tests completed, 3 failed
> Task :grpc-okhttp:test FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':grpc-okhttp:test'.
> There were failing tests. See the report at: file:///Users/suztomo/grpc-java/okhttp/build/reports/tests/test/index.html
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 34s
58 actionable tasks: 3 executed, 55 up-to-date
The build works fine in my Debian machine. (I also see this repository has setup Travis CI enabled.)
suztomo@suztomo:~/grpc-java$ ./gradlew cleanTest :grpc-okhttp:test --tests=io.grpc.okhttp.OkHttpClientTransportTest
*** Skipping the build of codegen and compilation of proto files because skipCodegen=true
* Skipping the build of Android projects because skipAndroid=true
BUILD SUCCESSFUL in 5s
58 actionable tasks: 2 executed, 56 up-to-date
Therefore I think I’ll need to setup something for the failing environment to make the test pass.
While I continue to dig further, I appreciate if anyone know the prerequisite for OkHttpClientTransportTest.
Issue Analytics
- State:
- Created 2 years ago
- Comments:15 (15 by maintainers)
Top Results From Across the Web
io.grpc.okhttp.OkHttpTransportTest ... - GitHub
We are working on s390x platform and facing below test failure while building gRPC-java master. We are using protoc v3.0.2 and v3.0.0-javalite.
Read more >Support okhttp3 in the public interface of grpc-okhttp #8732
grpc -okhttp does not support okhttp3 compatible versions in its public interface e.g. OkHttpChannelBuilder. Describe the solution you'd like.
Read more >can not build successfully in grpc-okhttp 1.27.0 version in ...
I am using grpc for cloud speech-to-text in android application, this is the libs I am using implementation 'io.grpc:grpc-okhttp:1.27.0' ...
Read more >Cannot create new gRPC project on macOS #416 - GitHub
I'm unable to run a new gRPC server project on macOS Mojave (10.14.5). ... over TLS is not supported on OSX due to...
Read more >grpc-java/OkHttpClientTransport.java at master - GitHub
grpc -java/okhttp/src/main/java/io/grpc/okhttp/OkHttpClientTransport.java ... withDescription("No error: A GRPC status of OK should have been sent"));.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@ejona86
new ServerSocket(0, 0, InetAddress.getLoopbackAddress())
solved the problem!Now
proxy_immediateServerClose
succeeds:This time standard output captured the invocation argument:
@ejona86 @sanjaypujare Thank you for your help in troubleshooting!
My Memo
Why
ServerSocket(0)
does not work?ServerSocket(0)
isServerSocket(port: 0, backlog: 50, bindAddr: null)
.(
ServerSocket serverSocket = new ServerSocket(0, 50, loopbackAddress);
also works good.)https://docs.oracle.com/javase/8/docs/api/java/net/ServerSocket.html says:
InetAddress.getLoopbackAddress()
returnsInet4Address@2726 localhost/127.0.0.1
.How about ServerSocket(0, 50, null)?
This timed out… (Of course
ServerSocket(0)
is the alias toServerSocket(0, 50, null)
)How about 0.0.0.0?
This timed out…
How about 127.0.0.1?
This worked!
Any security system that blocks listening on 0.0.0.0 port 80?
In my Mac,
nc
command can listen on 0.0.0.0 port 80.What’s the difference in the client code?
when I use
InetAddress.getLoopbackAddress()
, then the client’sSocketFactory.createSocket
takes 127.0.0.1.In the bad case, the client was trying to create a socket to 0.0.0.0 (screenshot). As per https://serverfault.com/a/300408 (which mentions https://tools.ietf.org/html/rfc1122#page-30 ), address 0.0.0.0 must not be sent.
How about specifying proxyAddress with InetAddress.getLoopbackAddress?
The code below also worked and clarifies the difference between the bad case and good case:
I found some more info https://superuser.com/questions/1307050/how-does-the-os-resolve-a-request-to-connect-to-0-0-0-0 but again it doesn’t explain the behavior difference between your Mac and my Mac