You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most gRPC client libraries allow multiple service clients to share a single HTTP connection to a server. This is typically presented as a separate "channel" abstraction, which used to initialize the service client. (For example, see https://grpc.io/docs/languages/java/basics/#client)
In akka-grpc, on the other hand, each service client creates its own connection to the server (via creating a ClientState, which creates an InternalChannel). While this works, it does mean that an akka-grpc client that uses multiple services will use many more HTTP connections than clients using other gRPC implementations. In some contexts (e.g. load testing), this difference can be significant.
Would it be possible to add support for reusing a single HTTP connection with multiple service clients? I think exposing a channel abstraction, like other gRPC libraries, would be best, since it allows the library user to control how connections are shared between services.
The text was updated successfully, but these errors were encountered:
Most gRPC client libraries allow multiple service clients to share a single HTTP connection to a server. This is typically presented as a separate "channel" abstraction, which used to initialize the service client. (For example, see https://grpc.io/docs/languages/java/basics/#client)
In akka-grpc, on the other hand, each service client creates its own connection to the server (via creating a ClientState, which creates an InternalChannel). While this works, it does mean that an akka-grpc client that uses multiple services will use many more HTTP connections than clients using other gRPC implementations. In some contexts (e.g. load testing), this difference can be significant.
Would it be possible to add support for reusing a single HTTP connection with multiple service clients? I think exposing a channel abstraction, like other gRPC libraries, would be best, since it allows the library user to control how connections are shared between services.
The text was updated successfully, but these errors were encountered: