Exception when "echo > /dev/tcp/localhost/8877" on the app's side

Question

The availability of a Java Spring-boot gRPC application is tested with a bash script.

The script determines the availability of app by:

echo > /dev/tcp/<apps-ip>/8877 
e.g. echo > /dev/tcp/localhost/8877

However this causes the application to print a stacktrace:

[INFO ] [2020-10-06 01:49:35.702] [thread=grpc-default-worker-ELG-1-2] [OpID=] [function=connections] [message=Transport failed]
io.grpc.netty.shaded.io.netty.handler.codec.http2.Http2Exception: HTTP/2 client preface string missing or corrupt. Hex dump for received bytes: 0a
    at io.grpc.netty.shaded.io.netty.handler.codec.http2.Http2Exception.connectionError(Http2Exception.java:103) ~[grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.handler.codec.http2.Http2ConnectionHandler$PrefaceDecoder.readClientPrefaceString(Http2ConnectionHandler.java:306) ~[grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.handler.codec.http2.Http2ConnectionHandler$PrefaceDecoder.decode(Http2ConnectionHandler.java:239) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.handler.codec.http2.Http2ConnectionHandler.decode(Http2ConnectionHandler.java:438) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:498) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:437) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:475) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [grpc-netty-shaded-1.31.1.jar!/:1.31.1]
    at java.lang.Thread.run(Thread.java:834) [?:?]

This exception comes up if there is a TLS mismatch between client and server (in gRPC sense) and/or if client and server use different HTTP versions.

I believe that in this particular case it is the HTTP version mismatch.

Can someone help me fix this? Or propose another way of testing the availability of the Spring-boot app?

Answer 1

What did the trick for me was employing, the well known wait-for-it.sh

In it they use nc -z command to test the connection, which does not do connect(2) like echo > /dev/tcp/<apps-ip>/8877 and thus there is no exception on my app's side.