Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

grpc Client-Streaming Java Client gets io.grpc.StatusRuntimeException: UNAVAILABLE: HTTP status code 503

See original GitHub issue

I have a grpc Nodejs server behind a HAproxy and client-streaming rpc java maven. When i run the java client it return an error:

io.grpc.StatusRuntimeException: UNAVAILABLE: HTTP status code 503 invalid content-type: text/html headers: Metadata(:status=503,cache-control=no-cache,content-type=text/html) DATA-----------------------------

503 Service Unavailable

No server is available to handle this request. </body></html>

I already test a rpc client streaming with Nodejs and it worked.

My java client code:

public class App {
    public static void main(String[] args) throws InterruptedException {
        WebRTCStats stat = WebRTCStats.newBuilder().setUserId("abc").build();
        SendWebRTCStats(stat);
    }

    public static void SendWebRTCStats(WebRTCStats stat) throws InterruptedException {
        ManagedChannel channel = ManagedChannelBuilder.forTarget("example.com:443").useTransportSecurity()
                .build();
        ClientGrpc.ClientStub stub = ClientGrpc.newStub(channel);

        StreamObserver<Stat.Status> responseObserver = new StreamObserver<Stat.Status>() {
            @Override
            public void onNext(Stat.Status status) {

            }

            @Override
            public void onError(Throwable t) {
                t.printStackTrace();
            }

            @Override
            public void onCompleted() {
                System.out.print("complete");
            }
        };
        StreamObserver<WebRTCStats> requestObserver = stub.sendWebRTCStats(responseObserver);
        try {
            // Send numPoints points randomly selected from the features list.

            requestObserver.onNext(stat);
            // Sleep for a bit before sending the next one.

        } catch (RuntimeException e) {
            // Cancel RPC
            requestObserver.onError(e);
            throw e;
        }
        // Mark the end of requests
        requestObserver.onCompleted();

        // Receiving happens asynchronously

    }
}

My NodeJS server:

const PROTO_PATH = './stat.proto';
const grpc = require('grpc');
const protoLoader = require('@grpc/proto-loader');
const fs = require('fs');
const tcp = require('./using.js');

let packageDefinition = protoLoader.loadSync(PROTO_PATH);

let protoDescriptor = grpc.loadPackageDefinition(packageDefinition);

const server = new grpc.Server();


server.addService(protoDescriptor.Client.service, {
    SendWebRTCStats: async (call, callback) => {
        call.on('data', value => {
            console.log(value);
            tcp.sendLog("test", value);
        });

        call.on('end', () => {
            callback(null, { status: 'success' });
        })
    },
});

let credentials = grpc.ServerCredentials.createSsl(
    fs.readFileSync('ca.cer'), [{
    cert_chain: fs.readFileSync('cer.crt'),
    private_key: fs.readFileSync('cer_key.key')
}], false);

server.bind("0.0.0.0:443", credentials);
console.log("Server running at 443");
server.start();

Can this problem occurs by different implementations of different libraries of language in GRPC?

Issue Analytics

State:
Created 3 years ago
Comments:6 (3 by maintainers)

Top GitHub Comments

1reaction

bettafish15commented, Nov 11, 2020

@ericgribkoff omg thanks so much for your help. The problem go away when i use forTarget() without port, my proxy and my client is fine . I wasted whole day for this haha

0reactions

ericgribkoffcommented, Nov 11, 2020

useTransportSecurity() is actually a server-side option? I thought your server here was Node. But yes, both the server and client need to be using TLS for the connection to work.

You may already have this part figured out as shown by the latest error message posted, but in case it helps: the default for a Java client is actually to use TLS. As long as you’re not invoking usePlaintext() on the Java channel builder, TLS should be used. You can see a brief example of how TLS is configured for Java here. You may need to configure your Java channel to accept the cert provided by the server as shown, but even if not, that should result in a much more helpful error (e.g., the “unable to find valid certification path to requested target” message returned by the Java client).