How to use gRPC service invocations?
See original GitHub issueAfter following the Invoking a Grpc endpoint example, I wanted to give it a try.
So I have created two applications, a server and a client, both using Spring Boot. They share a common submodule that holds the Protobuf definitions, and that generates the corresponding Java classes.
Client
The server has this in its Spring Boot application.yml:
grpc:
port: 5005
I start the sidecar for that application with dapr run --app-id user-service -P grpc -p 5005
, and then run the app from my IDE. The sidecar logs (among other things)
INFO[0026] application discovered on port 5005 app_id=user-service instance=edsger scope=dapr.runtime type=log ver=1.1.2
INFO[0026] actor runtime started. actor idle timeout: 1h0m0s. actor scan interval: 30s app_id=user-service instance=edsger scope=dapr.runtime.actor type=log ver=1.1.2
INFO[0026] placement tables updated, version: 0 app_id=user-service instance=edsger scope=dapr.runtime.actor.internal.placement type=log ver=1.1.2
ERRO[0026] error getting topic list from app: rpc error: code = Unimplemented desc = Method not found: dapr.proto.runtime.v1.AppCallback/ListTopicSubscriptions app_id=user-service instance=edsger scope=dapr.runtime type=log ver=1.1.2
INFO[0026] dapr initialized. Status: Running. Init Elapsed 26598.345999999998ms app_id=user-service instance=edsger scope=dapr.runtime type=log ver=1.1.2
But I’m not sure if that’s relevant.
Server
The client has a Spring bean for the DaprClient
defined:
@Bean
public DaprClient daprClient() {
return new DaprClientBuilder().build();
}
And it uses that bean like so:
return daprClient.invokeMethod(APP_ID, "register", user, HttpExtension.NONE, RegisterResponse.class)
.blockOptional()
.map(response -> response.userId)
.map(UUID::fromString)
.orElse(null);
I start the sidecar for the client with dapr run --app-id client
, and then start the client itself from my IDE.
When I invoke an endpoint on the client (which will eventually be done by a JavaScript frontend app, so it’s not going through Dapr here), I’m getting an exception in the logs:
java.net.ConnectException: Connection refused
at java.base/sun.nio.ch.Net.pollConnect(Native Method)
at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:660)
at java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:549)
at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:597)
at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:333)
at java.base/java.net.Socket.connect(Socket.java:648)
at okhttp3.internal.platform.Platform.connectSocket(Platform.kt:120)
at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:295)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
From inspecting the request using the debugger, it appears to me that the client tries to connect to localhost:3500 - but I don’t know why. Also, all the relevant breakpoints where located in classes with Http in their name. The DaprClientBuilder
even has a comment saying:
/**
* A builder for the DaprClient,
* Currently only and HTTP Client will be supported.
*/
I’m not sure how to interpret this. Should I be able to do gRPC-based service invocations from Java to Java? If so, how? How can I verify it is indeed using gRPC and not HTTP? How can I troubleshoot these connection issues?
Thanks in advance for any pointers you may have!
Issue Analytics
- State:
- Created 2 years ago
- Comments:13 (10 by maintainers)
Top GitHub Comments
@nobodyiam there was a discussion about how the mapping between gRPC and HTTP would work and due to the natural differences of the protocols, invoking an HTTP endpoint from the gRPC Dapr API would not result in a mapping that we thought was a good customer experience. On the other hand, invoking a gRPC endpoint from the HTTP Dapr API was OK. So we decided to make this change in the SDKs where only the service invocation APIs would default to HTTP. For more details, see: https://github.com/dapr/dapr/issues/2342
Thanks for confirming, and an additional thank you for helping me out in understanding this!