Variation: akka-grpc server scala with grpc-java client tester

https://travis-ci.org/akka/akka-grpc/jobs/362603376

[info] Running test status_code_and_message
[info] [INFO] [04/05/2018 12:45:16.399] [pool-1-thread-1-ScalaTest-running-GrpcInteropSpec] [akka.actor.ActorSystemImpl(default)] Exception thrown, unbinding
[error] org.scalatest.exceptions.TestFailedException
[error] 	at org.scalatest.Assertions.newAssertionFailedException(Assertions.scala:528)
[error] 	at org.scalatest.Assertions.newAssertionFailedException$(Assertions.scala:527)
[error] 	at org.scalatest.WordSpec.newAssertionFailedException(WordSpec.scala:1881)
[error] 	at org.scalatest.Assertions.fail(Assertions.scala:1121)
[error] 	at org.scalatest.Assertions.fail$(Assertions.scala:1117)
[error] 	at org.scalatest.WordSpec.fail(WordSpec.scala:1881)
[error] 	at com.lightbend.grpc.interop.GrpcInteropTests.withGrpcServer(GrpcInteropTests.scala:74)
[error] 	at com.lightbend.grpc.interop.GrpcInteropTests.$anonfun$grpcTests$4(GrpcInteropTests.scala:50)
[error] 	at com.lightbend.grpc.interop.GrpcInteropTests.pendingTestCaseSupport(GrpcInteropTests.scala:86)
[error] 	at com.lightbend.grpc.interop.GrpcInteropTests.$anonfun$grpcTests$3(GrpcInteropTests.scala:49)
[error] 	at org.scalatest.OutcomeOf.outcomeOf(OutcomeOf.scala:85)
[error] 	at org.scalatest.OutcomeOf.outcomeOf$(OutcomeOf.scala:83)
[error] 0m	at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
[error] 	at org.scalatest.Transformer.apply(Transformer.scala:22)
[error] 	at org.scalatest.Transformer.apply(Transformer.scala:20)
[error] 	at org.scalatest.WordSpecLike$$anon$1.apply(WordSpecLike.scala:1078)
[error] 	at org.scalatest.TestSuite.withFixture(TestSuite.scala:196)
[error] 	at org.scalatest.TestSuite.withFixture$(TestSuite.scala:195)
[error] 	at org.scalatest.WordSpec.withFixture(WordSpec.scala:1881)
[error] 	at org.scalatest.WordSpecLike.invokeWithFixture$1(WordSpecLike.scala:1076)
[error] 	at org.scalatest.WordSpecLike.$anonfun$runTest$1(WordSpecLike.scala:1088)
[error] 	at org.scalatest.SuperEngine.runTestImpl(Engine.scala:289)
[error] 	at org.scalatest.WordSpecLike.runTest(WordSpecLike.scala:1088)
[error] 	at org.scalatest.WordSpecLike.runTest$(WordSpecLike.scala:1070)
[error] 	at org.scalatest.WordSpec.runTest(WordSpec.scala:1881)
[error] 	at org.scalatest.WordSpecLike.$anonfun$runTests$1(WordSpecLike.scala:1147)
[error] 	at org.scalatest.SuperEngine.$anonfun$runTestsInBranch$1(Engine.scala:396)
[error] 	at scala.collection.immutable.List.foreach(List.scala:389)
[error] 	at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:384)
[error] 	at org.scalatest.SuperEngine.runTestsInBranch(Engine.scala:373)
[error] 	at org.scalatest.SuperEngine.$anonfun$runTestsInBranch$1(Engine.scala:410)
[error] 	at scala.collection.immutable.List.foreach(List.scala:389)
[error] 	at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:384)
[error] 	at org.scalatest.SuperEngine.runTestsInBranch(Engine.scala:379)
[error] 	at org.scalatest.SuperEngine.runTestsImpl(Engine.scala:461)
[error] 	at org.scalatest.WordSpecLike.runTests(WordSpecLike.scala:1147)
[error] 	at org.scalatest.WordSpecLike.runTests$(WordSpecLike.scala:1146)
[error] 	at org.scalatest.WordSpec.runTests(WordSpec.scala:1881)
[error] 	at org.scalatest.Suite.run(Suite.scala:1147)
[error] 	at org.scalatest.Suite.run$(Suite.scala:1129)
[error] 	at org.scalatest.WordSpec.org$scalatest$WordSpecLike$$super$run(WordSpec.scala:1881)
[error] 	at org.scalatest.WordSpecLike.$anonfun$run$1(WordSpecLike.scala:1192)
[error] 	at org.scalatest.SuperEngine.runImpl(Engine.scala:521)
[error] 	at org.scalatest.WordSpecLike.run(WordSpecLike.scala:1192)
[error] 	at org.scalatest.WordSpecLike.run$(WordSpecLike.scala:1190)
[error] 	at org.scalatest.WordSpec.run(WordSpec.scala:1881)
[error] 	at org.scalatest.tools.Framework.org$scalatest$tools$Framework$$runSuite(Framework.scala:314)
[error] 	at org.scalatest.tools.Framework$ScalaTestTask.execute(Framework.scala:507)
[error] 	at sbt.ForkMain$Run$2.call(ForkMain.java:300)
[error] 	at sbt.ForkMain$Run$2.call(ForkMain.java:290)
[error] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[error] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[error] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[error] 	at java.lang.Thread.run(Thread.java:748)
[error] Caused by: java.lang.AssertionError: expected:<UNKNOWN> but was:<CANCELLED>
[error] 	at org.junit.Assert.fail(Assert.java:88)
[error] 	at org.junit.Assert.failNotEquals(Assert.java:834)
[error] 	at org.junit.Assert.assertEquals(Assert.java:118)
[error] 	at org.junit.Assert.assertEquals(Assert.java:144)
[error] 	at io.grpc.testing.integration.AbstractInteropTest.statusCodeAndMessage(AbstractInteropTest.java:1507)
[error] 	at io.grpc.testing.integration2.GrpcJavaClientTester.statusCodeAndMessage(GrpcJavaClientTester.java:126)
[error] 	at io.grpc.testing.integration2.TestServiceClient.runTest(TestServiceClient.java:186)
[error] 	at io.grpc.testing.integration2.TestServiceClient.run(TestServiceClient.java:93)
[error] 	at com.lightbend.grpc.interop.IoGrpcClient$.run(IoGrpcClient.scala:20)
[error] 	at com.lightbend.grpc.interop.GrpcInteropTests.runGrpcClient(GrpcInteropTests.scala:80)
[error] 	at com.lightbend.grpc.interop.GrpcInteropTests.$anonfun$grpcTests$5(GrpcInteropTests.scala:50)
[error] 	at com.lightbend.grpc.interop.GrpcInteropTests.withGrpcServer(GrpcInteropTests.scala:62)
[error] 	... 47 more
[info] [info] - should pass the status_code_and_message integration test *** FAILED ***
[info] [info]   org.scalatest.exceptions.TestFailedException was thrown. (GrpcInteropTests.scala:74)

See: https://github.com/lightbend/akka-grpc/pull/47/files#r171284601

Those versions we could generate the same way we generate akka.Version -- thanks to this these versions would be surely aligned with what the build is using.

As long as we have a plain protoc plugin we should be able to integrate with gradle nicely as well:

task.plugins {
  // Add grpc output without any option.  grpc must have been defined in the
  // protobuf.plugins block.
  // This yields
  // "--grpc_out=/path/to/output" on the protoc commandline.
  grpc { }
}

https://github.com/google/protobuf-gradle-plugin

Note that that's the official google gradle plugin

Seems we want to integrate with https://github.com/thesamet/sbt-protoc rather than scalapb directly.
It also will allow us to generate java inside scala (sbt) projects.

It will also make adding our codegen easier, see:

PB.targets in Compile := Seq(
  scalapb.gen() -> (sourceManaged in Compile).value,
  MyCodeGenerator -> (sourceManaged in Compile).value
)

https://github.com/thesamet/sbt-protoc/tree/master/examples/custom-gen

When java_package is not defined in the .proto, we should fall back to the package

When an interop test fails, all subsequent calls also fail.

Check whether that's something we should fix, or something 'harmless' in the test framework.

Akka-gRPC client should allow setting up circuit breaking. Related to #137

akka-grpc's server implementation will need to support both modeled and raw headers when reading headers from a request. Play has recently changed to use raw headers so support for raw headers is important if we want to embed akka-grpc in Play.

From reading the akka-grpc source I believe that the code that reads the Message-Encoding header may need to be changed to handle raw headers as well as modeled headers. It should be OK to leave any code that emits modeled headers as it currently is.

Generated clients expose implementation details such as io.grpc.StatusException or related model (Status, Code).

We should replace all error handling and status model with akka-grpc specific classes.

• add PB.protoSources in Compile += target.value / "protobuf_external"
• document this is possible with an example?

Related to #6

For Scala we could choose to invoke scalapb as a protoc plugin, or use https://github.com/CharlesAHunt/scalapb-gradle-plugin

Choice between scala and java exists. I think setting for choosing server/client/both is missing.

That should also influence suggestedDependencies.

Use Service discovery so host:port are not hardcoded.

To abstract this away for the end user. Does that make sense @renatocaval ?

We have now a javadsl package but all Scala classes on still in akka.http.grpc. We should move them to akka.http.grpc.scaladsl or at least some of them.

The goal is to have an initial version hardcoded in interop-tests

It depends on what the result of the generated code is. E.g. if the result is a PartialFunction[HttpRequest, HttpResponse, the combination is a simple orElse.

It's currently _ or Any.

in parameter

The _ in the in: Source[Req, _] makes sense on the client side since it can't be used there (not materialized by user code). On the server side it doesn't make sense to have _, because something is actually materialized there. Better to have NotUsed on both sides (well it's the same trait on both sides so it must be the same on both sides)?

out return value

It seems like the mat val of the in is the Any mat val of the returned Source. That can be useful on the client side but should then be expressed in the types. What does it mean on the server side?

You can use grpc-netty-shaded since grpc-java 1.9

grpc/grpc-java#2485

As discussed on zoom: perhaps this is needed rarely enough that we don't need to provide a poweruser client API for this, and instead allow users to the building blocks we use to generate the normal client API as well.

Make this works: https://github.com/lightbend/akka-grpc/tree/master/sbt-plugin/src/sbt-test/gen-scala-server/01-gen-basic-server

See #79 for the server side

That currently fails due to the -Dsbt.ivy.home=/localhome/jenkinsakka/.ivy2 option.

The -Dsbt.ivy.home=/localhome/jenkinsakka/.ivy2 is probably there because /home/jenkinsakka is an NFS mount, and we want each node to have its own ivy cache?

related to #79

Either support plain text mode as the Netty client is already doing, or have a utility for setting up dummy test certificates on both sides.

Related akka/akka-http#1849

In our interop tests, when the FromRequestUnmarshaller[SimpleRequest] fails (completes the future with an exception), the source is already consumed, but the request is still passed on to the next matching unmarshaller (which fails since the Source cannot be consumed twice). Is that unavoidable?

We use an example helloworld.proto in a number of places, but they have grown out of sync. Let's make them consistent again.

Current TestSerivceClietimplementation is tightly coupled with the grpc-java implementation. We need to refactor it or add a new variant that uses the akka-gprc client stub (see #38).

Ideally, we should be able to swap channels. We will start using a netty channel that will be later replaced by an akka-http channel.

The interop test can then verify a few combinations:

• grpc-java server with grpc-java client
• akka-grpc server with grpc-java client
• akka-grpc server with akka-grpc stub using netty channel
• akka-grpc server with akka-grpc stub using akka-http channel

Something is iffy with how to control the package name of the generated code.

Seems like the file name of the .proto is used. hello-world.proto results in hello-world in the package name, which is obviously not valid, and using the file name is probably not a good idea.

What role does the other options have?

package helloworld; in the .proto doesn't seem to have any effect?

option java_package = "io.grpc.examples"; seems to be some root package, but is that how it's supposed to be used? Shouldn't that be the package?

Would also be good to clarify in examples/doc what the other options are good for, or remove them from example:

option java_multiple_files = true;
option java_outer_classname = "HelloWorldProto";

As discussed in #56

Might be easier to maintain than using builders.

We can also set up CI on windows using https://www.appveyor.com/

We should implement element based backpressure.

Some pointers:

• https://www.beyondthelines.net/computing/grpc-akkastream-back-pressure/
• btlines/grpcakkastream#17
• https://github.com/grpc/grpc-java/blob/master/examples/src/main/java/io/grpc/examples/manualflowcontrol/ManualFlowControlServer.java

With that in place I assume that we can remove the buffer on the client side. See comment

      // channel calls don't support back-pressure so we need to buffered it
      // and eventually fail the stream

At client side one may need to tweak how the client should work.

The grpc-java implementation has with methods, e.g.: withCompression, withExecutor, withInterceptors, etc. Those methods are added to the stub and returns a new tweaked stub.

We could have something similar or take an approach similar to Lagom's ServiceCall. To be discussed and analysed.

Generated code is ultimately run by the scripted tests, but the turn-around is high.

If possible we should compile check it just after generation.

So we don't have to hard-code it in codegen/src/main/scala/akka/grpc/gen/scaladsl/ScalaMarshallersCodeGenerator.scala

They do things a bit differently than plain HTTP, e.g. I think it may be nice to render ??? errors as "UNIMPLEMENTED"

https://github.com/grpc/grpc/blob/master/doc/statuscodes.md