This room is dedicated to discussions between Akka committers for coordinating the development process—for general questions and discussions around the usage of Akka please head over to akka/akka. For more info see: http://bit.ly/akka-gitter
compile in this module depends on CompileJdk9 in remote'
show akka-remote/TestJdk9/sourceDirectories lists the right place
akka-remote/TestJdk9/test doesn’t run anything
withChannelBuilderOverrides is a temporary API that will go away when we ever move to Akka HTTP for the client as well
the reality is that I got stuck a couple of time into upgrading to latest 2.5 (something JVM specific sneaked in in streams or streams testkit need time to investigate), I will possibly have some time to dedicate in the next weeks (or maybe around Christmas ...), is it a blocker for you?
@raboof Hello. I with @dmi3zkm were tested keep-alive header and here what we found
Before testing I had a firm assumption that akka-grpc issues new http connection on each grpc call.
Then I've found out that I could set client's keep alive related setting using ChannelBuilderOverrides.
The code follows:
GrpcClient(GrpcClientSettings.connectToServiceAt("localhost", 9091).withTls(false)
.withChannelBuilderOverrides(_.keepAliveWithoutCalls(true)
.keepAliveTime(10, TimeUnit.MINUTES)
.keepAliveTimeout(1, TimeUnit.MINUTES)))Searching code I've found client's idleTimeout which is set to 30 minutes by default.
Although, using the wireshark I couldn't find any Keep-Alive headers in request/response packets, the connection was reused between multiple grpc calls.
After setting idleTimeout to 100 millis and waiting for 1 sec between each call in my test, I've seen connection reestablishing packets in the wireshark.
Then I googled for http2 (which grpc uses underneath) specification and found out the section 8.1.2.2 Connection-Specific Header Fields which states:
HTTP/2 does not use the Connection header field to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other >means. An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields >MUST be treated as malformed (Section 8.1.2.6).
The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any value other than "trailers".
This means that an intermediary transforming an HTTP/1.x message to HTTP/2 will need to remove any header fields nominated by the Connection header field, >along with the Connection header field itself. Such intermediaries SHOULD also remove other connection-specific header fields, such as Keep-Alive, Proxy->Connection, Transfer-Encoding, and Upgrade, even if they are not nominated by the Connection header field.
This drives me to the consclusion that http2 omits Keep-Alive headers at all and grpc connections on top of http2 is persistent out of the box.
Please, confirm or correct my assumptions.
Keep-Alive, Connection itself etc. I suspect there's more to keepalive in grpc though: perhaps indeed keepAliveWithoutCalls is just a matter of setting timeouts, but it suggests there also exists a 'keepalive with calls', which likely does need explicit code on the server side?
troubles begin when I need the materialized value of the downstream flow, flatMapConcat don't have a 'Mat' version (I can see why as the general case will require folding over multiple materialized values) and the downstream flow is not known before the prefix is consumed so I'm kind'a stuck... I'd be happy to be able to utilize something like Flow.futureFlow to obtain a Future mat-value but I can't see how can this be done when the fuure flow is based on the consumed prefix... any ideas?
