When a server is created with a random port (e.g. VertxServerBuilder.forAddress(vertx, host, 0)), the internal ServerID is "<host>:0". Creating more servers with random ports also assigns the same ServerID. Since ServerID is the key in VertxServer's internal static map, only one random-port-server can be started.

Server shutdown might be blocking and should be wrapped in an execute blocking operation.

Version

1.25.0

Context

It is now possible to use optional in proto3 with a flag.

However it produces the following error with vertx's generator:

`test_proto3_optional_helloworld` is a proto3 file that contains optional fields, but code generator protoc-gen-grpc_java hasn't been updated to support optional fields in proto3. Please ask the owner of this code generator to support proto3 optional.

Do you have a reproducer?

Create a file for Protobufs 3.13 and later with the exact name:

test_proto3_optional_helloworld.proto

syntax = "proto3";
package helloworld;

service HelloService {
    rpc GetHello(Hello) returns (Hello) {}
}

message Hello {
    optional bool some_field = 1;
}

test_proto3_optional prefix ensures the right flags are passed.

https://github.com/salesforce/grpc-java-contrib/blob/master/rxgrpc/README.md

gRPC supports compression, we should document it and make it usable from Vert.x generated artifacts. There is no work for client, but the server generation needs to get configuration generation and set the compression on response messages.

Hi,
I'd like to prose the following enhancement to VertxChannelBuilder.
When creating new channel the HttpClientOptions aren't exposed or editabled and takeover the defaults. I'd like to add either convenient method to disable hostname verification or expose HttpClientOptions object to pass the parameter.

It seems that since JDK 11 the hostname verification procedure has changed. Even for cases when trustAll(true) is used, the hostname verification is still applied and invalid hostnames e.g. localhost certificates may fail when accessed from outside. The same use case works fine on JDK 8 with dummy localhost certificates

Cc @spisiakm

Describe the feature

At the moment AsyncMap-s provided by SharedData have key and value type restrictions: primitive types, java.io.Serializable and io.vertx.core.shareddata.impl.ClusterSerializable. None of these could be used for POJO objects that doesn't implement Serializable (ClusterSerializable is internal interface - so it's very unlikely someone to implement it).
Support for AsyncMap key.value types could be extended using the same approach used in EventBus - by registering codecs. Codecs in both cases could even use the same interface - after all they would serve single concept - serialize and deserialiize custom objects.

Note: If such support is added, vertx could auto register codecs for JsonObject/JsonArray/Buffer instead of implementing ClusterSerializable (which is not public class and seems little strange in the documentation) . Probably ClusterSerializable could be even removed.
I don't see in current SharedData doc any notice which types are supported. And it would be little hard to explain because of internal ClusterSerializable.

Note: Event bus supports byte[]. There's no reason for AsymcMap to do not support byte[] as value type (at least to have similar supported types for event bus and AsyncMap)

Use cases

Having a cluster wide async map with key.value types that are legacy or not in developer control e.g. POJOs.

Contribution

In generated code, there are some codes like this:

public void invoke(Req request, io.grpc.stub.StreamObserver<Resp> responseObserver) {
      switch (methodId) {
        case METHODID_FOO:
          serviceImpl.foo((FooRequest) request,
              (io.vertx.core.Promise<FooResponse>) io.vertx.core.Promise.<FooResponse>promise().future().setHandler(ar -> {
                if (ar.succeeded()) {
                  ((io.grpc.stub.StreamObserver<FooResponse>) responseObserver).onNext(ar.result());
                  responseObserver.onCompleted();
                } else {
                  responseObserver.onError(ar.cause());
                }
              }));
          break;
       ................
    }
}

The promise().future().setHandler was deprecated

Vertx version: 3.9.4

We would like to have a way to collect metrics for the end user.

For reference: https://github.com/grpc-ecosystem/grpc-opentracing/tree/master/java/src/main/java/io/opentracing/contrib

I noticed that when upgrading my gRPC client from Vert.x 4.0.2 to 4.0.3, then it is not able to handle properly the HTTP responses with a status different than 200 (at least with status 401 and 403).

Indeed gRPC relies on HTTP/2 for its transport and before reaching the gRPC server, the gRPC request can go through multiple intermediaries (HTTP proxies). And such intermediary can check the incoming HTTP request and decide to forward it or to stop it by sending a plain HTTP response. The client then can map the HTTP status code to a gRPC one, as described on
https://grpc.github.io/grpc/core/md_doc_http-grpc-status-mapping.html .

The setup to reproduce is pretty simple:

• have a plain HTTP server that answers only 401
• have a gRPC client that send a gRPC request to that host.

With Vert.x 4.0.2 that works as expected: a StatusRuntimeException is raised and the Status attached to this Exception is UNAUTHENTICATED. Here is the output:

Could not reach server UNAUTHENTICATED: HTTP status code 401
invalid content-type: null
trailers: Metadata(:status=401,content-length=0)
Status: Status{code=UNAUTHENTICATED, description=HTTP status code 401
invalid content-type: null
trailers: Metadata(:status=401,content-length=0), cause=null}

With Vert.x 4.0.3 that does not work so well: StatusRuntimeException is raised but the Status attached to this Exception is UNKNOWN and we have the following traces:

Could not reach server UNKNOWN
Status: Status{code=UNKNOWN, description=null, cause=java.lang.UnsupportedOperationException
	at io.grpc.netty.AbstractHttp2Headers.setLong(AbstractHttp2Headers.java:465)
	at io.grpc.netty.AbstractHttp2Headers.setLong(AbstractHttp2Headers.java:26)
	at io.netty.handler.codec.http2.DefaultHttp2ConnectionDecoder$FrameReadListener.onHeadersRead(DefaultHttp2ConnectionDecoder.java:403)
	at io.netty.handler.codec.http2.Http2InboundFrameLogger$1.onHeadersRead(Http2InboundFrameLogger.java:65)
	at io.netty.handler.codec.http2.DefaultHttp2FrameReader$1.processFragment(DefaultHttp2FrameReader.java:457)
	at io.netty.handler.codec.http2.DefaultHttp2FrameReader.readHeadersFrame(DefaultHttp2FrameReader.java:464)
	at io.netty.handler.codec.http2.DefaultHttp2FrameReader.processPayloadState(DefaultHttp2FrameReader.java:254)
	at io.netty.handler.codec.http2.DefaultHttp2FrameReader.readFrame(DefaultHttp2FrameReader.java:160)
	at io.netty.handler.codec.http2.Http2InboundFrameLogger.readFrame(Http2InboundFrameLogger.java:41)
	at io.netty.handler.codec.http2.DefaultHttp2ConnectionDecoder.decodeFrame(DefaultHttp2ConnectionDecoder.java:181)
	at io.netty.handler.codec.http2.Http2ConnectionHandler$FrameDecoder.decode(Http2ConnectionHandler.java:378)
	at io.netty.handler.codec.http2.Http2ConnectionHandler.decode(Http2ConnectionHandler.java:438)
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
...
}

It seems that with Vert.x 4.0.3, the parsing of the HTTP/2 headers fail so the status default to UNKNOWN . So of course that has impacts when we have to take decision based on that Exception's Status.

After a few tries with forcing different versions of Netty, I found that this regression is coming in Netty 4.1.60.Final.
With Vert.x 4.0.3 but forcing Netty to 4.1.59.Final it is working fine.

Find attached the small test I use to emphasize this regression, it is fully based on the gRPC example you documented on : https://vertx.io/docs/vertx-grpc/java/ . See the class Client.

vertx-grpc-example.zip

When I tried to compile my .proto files using maven, I got the error:

[ERROR] 2) io.vertx:protoc-gen-grpc-java:osx-x86_64:1.3.0
[ERROR] 
[ERROR] ----------
[ERROR] 1 required artifact is missing.

It can be fixed by replacing the pluginArtifact section from io.vertx:protoc-gen-grpc-java:1.3.0:${os.detected.classifier} to io.vertx:protoc-gen-grpc-java:1.3.0:exe:${os.detected.classifier}.

So I think it should be a mistake in the document.

If the connection is already closed, the future will not be completed because the method calls on observer will throw an exception similar to:

ERROR i.v.c.impl.ContextImpl Unhandled exception
io.grpc.StatusRuntimeException: CANCELLED: call already cancelled
	at io.grpc.Status.asRuntimeException(Status.java:524)
	at io.grpc.stub.ServerCalls$ServerCallStreamObserverImpl.onCompleted(ServerCalls.java:368)
	at io.vertx.grpc.stub.GrpcWriteStream.end(GrpcWriteStream.java:65)
	at io.vertx.core.streams.WriteStream.end(WriteStream.java:75)

You should wrap the calls to observer in try ..., e.g.

@Override
  public Future<Void> write(T data) {
    try {
      observer.onNext(data);
    } catch (Throwable t) {
      return Future.failedFuture(new VertxException(t));
    }
    return Future.succeededFuture();
  }

Something like:

.useSsl(options -> {
          options
            .setSsl(true)
            .setUseAlpn(true)
           .setTrustAll(true);
        }
      )

I am using the latest 4.0.0-SNAPSHOT of the Vert.x stack. The WriteStream that is passed to a server stream method handler does not expose the ServerCallStreamObserver.setOnCancelHandler method so it is impossible to be notified if the client cancels the stream. This was possible to do in the 3.x version of the generated code like so :

var observer = (ServerCallStreamObserver<Response>) writeStream.writeObserver();
observer.setOnCancelHandler(() -> handleCancel());

Or is there a way to do it that have not been able to find ? Thanks.

I am trying to resolve this grpc project in OSGi framework but I see there is no OSGi metadata for this project

1. are you plunning to provide support for OSGi in the future?
2. How do I wrap this as OSGi bundle. It will not resolve becaise of the codegen annotations. I dont think adding the annotation jar to runtime will help, this needs to pe processed and packaged.

I use the bnd plugin to add OSGi info to the jar

[INFO] --- bnd-maven-plugin:4.0.0:bnd-process (default-bnd-process) @ vertx-grpc ---
[INFO] Unable to determine whether the meta annotation io.vertx.codegen.annotations.Fluent applied to type io.vertx.grpc.GrpcBidiExchange provides bundle annotations as it is not on the project build path. If this annotation does provide bundle annotations then it must be present on the build path in order to be processed
[INFO] Unable to determine whether the meta annotation io.vertx.codegen.annotations.GenIgnore applied to type io.vertx.grpc.GrpcBidiExchange provides bundle annotations as it is not on the project build path. If this annotation does provide bundle annotations then it must be present on the build path in order to be processed
[INFO] Unable to determine whether the meta annotation io.vertx.codegen.annotations.VertxGen applied to type io.vertx.grpc.GrpcBidiExchange provides bundle annotations as it is not on the project build path. If this annotation does provide bundle annotations then it must be present on the build path in order to be processed
[INFO] Unable to determine whether the meta annotation io.vertx.docgen.Document applied to type io.vertx.grpc.package-info provides bundle annotations as it is not on the project build path. If this annotation does provide bundle annotations then it must be present on the build path in order to be processed
[INFO]

Thanks.

Version

4.0.2

Context

Upgrading to vertx-grpc 4.x seems to have broken support for gRPC verticles.

In the stack trace below, I can see that in the constructor of ActualServer a NettyServer is built that expects the VertxEventLoopGroup to have an EventLoop available.

However, VertxServer only seems to add an EventLoop to VertxEventLoopGroup after the ActualServer is created and so it blows up.

Am I missing something here?

java.lang.IllegalStateException
	at io.vertx.core.net.impl.VertxEventLoopGroup.next(VertxEventLoopGroup.java:37)
	at io.grpc.netty.NettyServer.<init>(NettyServer.java:141)
	at io.grpc.netty.NettyServerBuilder.buildTransportServers(NettyServerBuilder.java:640)
	at io.grpc.netty.NettyServerBuilder$NettyClientTransportServersBuilder.buildClientTransportServers(NettyServerBuilder.java:169)
	at io.grpc.internal.ServerImplBuilder.build(ServerImplBuilder.java:231)
	at io.grpc.internal.AbstractServerImplBuilder.build(AbstractServerImplBuilder.java:166)
	at io.vertx.grpc.VertxServer$ActualServer.<init>(VertxServer.java:98)
	at io.vertx.grpc.VertxServer$ActualServer.<init>(VertxServer.java:57)
	at io.vertx.grpc.VertxServer.lambda$start$1(VertxServer.java:170)
	at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
	at io.vertx.grpc.VertxServer.start(VertxServer.java:170)

I am using the latest 4.0.0-SNAPSHOT of the Vert.x stack. I tested this with the Java server app running on macOS 10.15.14, ubuntu 20.04, Windows 10 on a AdoptOpenJDK 11.0.7 JVM. I am using openssl test client like so :

openssl s_client -showcerts -servername grpc.example.com -connect grpc.example.com:443

I am setting the SSL options with the setPfxKeyCertOptions and setSni(true). The PFX/P12/PKCS 12 key store contains key/cert entries for all the hostnames the server is serving for, including "localhost", and for the sake of this example, "grpc.example.com". If I start a normal Vert.x HTTP/2 server, it responds to the test openssl command correctly, whereas the gRPC server does not.

Currently the integration uses the channelType to define the channel to use which force to create and leak a file descriptor. Instead it should use the channelFactory. Previous versions of gRPC only defined channelType, now channelFactory is present as well.

#54

Version

Vertx: 3.8.4
Netty: 4.1.44.Final
gRPC: 1.26.0
Linux, Alpine
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (IcedTea 3.8.0) (Alpine 8.171.11-r0)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)

Context

We found two hanged event loop threads in our logs. It seems that gRPC server shutdown use to block the thread the shutdown is called into and wait for channel to close. Furthermore, I suppose that the close of the channel is waiting to do something into exactly the same event loop thread.

The thread is:

[2020-Jan-13 16:52:26.544 UTC] [] [] [io.vertx.core.impl.BlockedThreadChecker] WARN Thread Thread[vert.x-eventloop-thread-0,10,main]=Thread[vert.x-eventloop-thread-0,10,main] has been blocked for 610568 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
at java.lang.Object.wait(Native Method) ~[?:1.8.0_171]
at java.lang.Object.wait(Object.java:502) ~[?:1.8.0_171]
at io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:252) ~[?:?]
at io.netty.channel.DefaultChannelPromise.await(DefaultChannelPromise.java:131) ~[?:?]
at io.netty.channel.DefaultChannelPromise.await(DefaultChannelPromise.java:30) ~[?:?]
at io.grpc.netty.NettyServer.shutdown(NettyServer.java:298) ~[?:?]
at io.grpc.internal.ServerImpl.shutdown(ServerImpl.java:273) ~[?:?]
at io.grpc.internal.ServerImpl.shutdown(ServerImpl.java:90) ~[?:?]
at io.vertx.grpc.VertxServer$ActualServer.lambda$stop$4(VertxServer.java:108) ~[?:?]
at io.vertx.grpc.VertxServer$ActualServer$$Lambda$1030/2059682670.handle(Unknown Source) ~[?:?]
at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369) ~[?:?]
at io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38) ~[?:?]
at io.vertx.core.impl.EventLoopContext$$Lambda$35/1779871850.run(Unknown Source) ~[?:?]
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) ~[?:?]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) ~[?:?]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) ~[?:?]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[?:?]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[?:?]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[?:?]
at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_171]

Do you have a reproducer?

I don't have any reproducer. It happen just once and I'm not sure for exact conditions. But suppose this is race condition and/or something specific to setup (e.g. OS).

Extra

Attaching thread dump
dev_threaddump.txt
Probably shutdown shall be run in blocking thread as it is made with start

Hi there! Fantastic job on Vertx, really love how it scales well to multiple services.

I've been trying to implement gRPC reflection on my Vertx gRPC server by adding in the regular gRPC service ProtoReflectionService. It was my understanding that the VertxServerBuilder wraps the services so that they use async calls rather than the traditional blocking ones, so I was just following the regular method of adding reflection found here.

import io.grpc.protobuf.services.ProtoReflectionService;

...

VertxServer server = VertxServerBuilder
                    .forAddress(vertx, config.hostName, config.port)
                    .addService(myservice)
                    .addService(ProtoReflectionService.newInstance())
                    .build();

However, I've found that occasionally the server doesn't respond to my reflection commands (using grpcurl). It does not seem to be blocking any threads, but rather waiting for a message it never receives, or missing messages. I wonder if this is a bug or just my misunderstanding of Vertx?

I'm running vertx 3.5.1 and using grpc-services 1.9.1

Perhaps there is another way of quickly enabling a reflection service that is Vertx specific which I have been missing?

vertx-grpc: 3.8.4
OS: Ubuntu 18.04
JDK: openjdk 8 and Oracle JDK 8

Problem:
Every VertxChannelBuilder.build method call creates a file descriptor that is not closed until the java process stop. Thus, for instance, if you create and shutdown many ManagedChannel-s you may get in lack of file descriptors.

Simple code to reproduce it is:

  while (true) {
    final VertxChannelBuilder builder = VertxChannelBuilder.forAddress(vertx, "localhost", 80).usePlaintext();
    final ManagedChannel channel = builder.build();
    channel.shutdownNow();
    channel.awaitTermination(10, TimeUnit.SECONDS);
    Thread.sleep(100);
  }

This is a reproducer maven project with main method:
vertx-grpc-fdleak.zip
It also dumps file descriptors got by java process after each iteration.

The problem is, as far as I understand resolving of channel type (in build). It creates channel that is never closed. This seem to produce file descriptor that is not closed.
I tried to change a little bit the code by closing the channel - then the problem was fixed - no file descriptor leakage. What I tried was to change last return with:

 final io.netty.channel.EventLoop eventLoop = context.nettyEventLoop();
 final io.netty.channel.Channel tempChannel = transport.channelFactory(false).newChannel();
 final Class<? extends io.netty.channel.Channel> channelType = tempChannel.getClass();
 eventLoop.register(tempChannel);
 tempChannel.close();
 return builder
   .eventLoopGroup(eventLoop)
   .channelType(channelType) // Ugly work around / perhaps contribute change to grpc
   .executor(command -> {
   if (Context.isOnEventLoopThread()) {
     context.executeFromIO(event -> command.run());
   } else {
     command.run();
   }
 }).build();

I imagine that the best approach here would be to resolve type with closing the channel (as in the code above) but also the class may be cached for an transport instance.

Version

since '4.0.0-milestone4' to '4.0.2'

Context

when using the library vertx-grpc (since '4.0.0-milestone4' to '4.0.2') with vert-core (since '4.0.0-milestone4' to '4.0.2') the following error is generated:

error: cannot find symbol
...future().setHandler(ar -> {....
----------^
symbol: method setHandler((ar)->{ if[...]; } })
...

Do you have a reproducer?

https://github.com/nx2501/vertx4-grpc-bug.git

Steps to reproduce

1. configure gradle on local development
2. use java 11
3. down project https://github.com/nx2501/vertx4-grpc-bug
4. cd vertx4-grpc-bug
5. gradle clean build

Extra

vert-core (since '4.0.0-milestone4' to '4.0.2') replace "setHandler()" with :
"onFailure()"
"onSuccess()"
"onComplete()"

If replace "setHandler()" with "onComplete()" works fine !!!

There is interest of using this from a polyglot side https://gitter.im/es4x/Lobby?at=5e158929821b826f5a84b787 Adding some basic annotations would ease the usability for this case and perhaps we can investigate if we can also update the code generator to include them too...

I try to use gRPC within vertx and created a ServerInterceptor to get the extraHeader from the metadata object.

The way to provide this information to the service is to pass the data into io.grpc.Context object. this Context can be statically asked for the value. Behind io.grpc.Context, there is a ThreadLocalContextStorage object.

So the data is bounded to the thread.

Can this be reliable used in a vertx environment? Or is there another "Best Practice" to hand over io.grpc.Metadata to the bounded service?

Hi,

I'm using version 3.4.1 and it is failing to make calls, because it cannot find the class LoadBalancer2.Factory, when creating a VertxChannelBuilder

Looking to latest code, looks that in master branch we no longer have the method loadBalancerFactory with that signature( that accepts that LoadBalancer2.Factory)

Is this a bug ? or am I missing any library in my project?

Kind regards

Questions

I tried to use version 4.0, but the compilation went wrong.
I did it according to the instructions in this document : https://vertx-web-site.github.io/docs/vertx-grpc/java/

using gradle

protobuf {
  protoc {
    artifact = "com.google.protobuf:protoc:3.2.0"
  }
  plugins {
    grpc {
      artifact = "io.vertx:protoc-gen-grpc-java:1.25.0"
    }
    vertx {
      artifact = "io.vertx:vertx-grpc-protoc-plugin:4.0.0.Beta3"
    }
  }
  generateProtoTasks {
    all()*.plugins {
      grpc
      vertx
    }
  }
}

Version

4.0.0.Beta3

Context

gradle error:

Execution failed for task ':generateProto'.
> Could not resolve all files for configuration ':protobufToolsLocator_vertx'.
   > Could not find vertx-grpc-protoc-plugin-4.0.0.Beta3-windows-x86_64.exe (io.vertx:vertx-grpc-protoc-plugin:4.0.0.Beta3).
     Searched in the following locations:
         https://repo.maven.apache.org/maven2/io/vertx/vertx-grpc-protoc-plugin/4.0.0.Beta3/vertx-grpc-protoc-plugin-4.0.0.Beta3-windows-x86_64.exe

Possible solution:
 - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html

Extra

env: win10, jdk8

When playing around with vertx-grpc I noticed a familiar warning regarding the deprecation of io.vertx.core.Future from the 3.8.0 release.

Given the proto:

...

option java_package = "examples";

service Greeter {
    rpc SayHello (HelloRequest) returns (HelloResponse) {
    };
}

...

A method is generated in GreeterGrpc.GreeterVertxImplBase with the signature:

public void sayHello(examples.HelloRequest request, io.vertx.core.Future<examples.HelloResponse> response)

The generated code should switch over to using the io.vertx.core.Promise interface. Perhaps it's possible to generate a second method for each rpc in the proto which uses a io.vertx.core.Promise instead of io.vertx.core.Future to allow users to switch off of the deprecated code, without breaking other users that don't want to switch yet? Not sure how feasible that would be.

• move the server blocking interceptor section as sub-section of the server section
• document server scaling
• document native transports support

In Vert.x 3.x, Vert.x provides its own compiled gRPC stubs for Vert.x API. This leads to maintain a fork of the grpc compiler which cannot be trivially achieved by anyone. It is agreed in Vert.x 4 to drop this.

Is there any plans to bump version of GRPC to 1.3.0?

I am a beginner with grpc and had the following basic doubt as to is there any restriction that we need to use "newVertxStub" on the client side when we use Vertx grpc and not "newStub" and similarly on the server side to use VertxImpl rather than Impl class for the service . I am just confused since the method name mentions Vertx so is there a need/benefit that only the ones with Vertx in the name are the correct methods to be used.
Also if there is no such need then what is the difference between the two and which one is supposed to be used in what scenarios?

I needed this answer urgently and had put up a question on google groups but did not get any response so had to create a issue here .
https://groups.google.com/forum/#!topic/vertx/hj6IyfeZLm4

Version 3.4.2. Tried openssl(tc-nativ-boring-static) and jdk(1.8_144). SSL works, ClientCert required does not seem to be advertised.
VertxServer server = VertxServerBuilder. forPort(vertx, 8080) //.useTransportSecurity(new File("certs/TestServer.chain"), // new File("certs/TestServerKey.pem"))
.useSSL(tcpsslOptions -> {
JksOptions trustOptions = new JksOptions()
.setPath("certs/truststore.jks")
.setPassword("testpw");
//PemTrustOptions trustOptions = new PemTrustOptions()
// .addCertPath("certs/TestCA.crt");
//PfxOptions trustOptions = new PfxOptions()
// .setPath("certs/testclient.p12")
// .setPassword("testpw");
HttpServerOptions options = (HttpServerOptions)tcpsslOptions;
options.setSsl(true)
.setUseAlpn(true)
.setClientAuth(ClientAuth.REQUIRED)
.setClientAuthRequired(true)
.setSni(true)
.setTrustStoreOptions(trustOptions)
.setTrustOptions(trustOptions)
.setKeyStoreOptions(new JksOptions()
.setPath("certs/server-keystore.jks")
.setPassword("testpw"))
//.setOpenSslEngineOptions(new OpenSSLEngineOptions().setSessionCacheEnabled(false))
}).addService(sd).build();`
openssl and jdk complain both that the "peer is not verified" or "peer is not authenticated".
I think netty and grpc stuff would work, it is probably a vertx issue. Can you please check?
If you need a complete testcase let me know.

Such transport would provide an improved integration with gRPC (e.g providing SNI support, vertx security, vertx web router) and also would ease Netty upgrade as grpc-netty would not impose the Netty version to use.

Describe the feature

The client stub methods should have the signature

Future<Reply> rpcName(Request request);

in addition to

void rpcName(Request request, Handler<AsyncResult<Reply>> handler);

Use cases

Makes using the client far less clunky.

Contribution

I can implement this feature if there's a chance my PR actually gets merged, I would do it for 3.9.4 and 4.0.0.

Requires docker. Works around a bunch of misunderstandings / packaging issues. Works around #78

Version

4.0.0.CR1

Context

Addresses the bug:

Execution failed for task ':framework:generateProto'.
> Could not resolve all files for configuration ':framework:protobufToolsLocator_grpc_java'.
   > Could not find vertx-grpc-4.0.0.CR1-osx-x86_64.exe (io.vertx:vertx-grpc:4.0.0.CR1).
     Searched in the following locations:
         https://jcenter.bintray.com/io/vertx/vertx-grpc/4.0.0.CR1/vertx-grpc-4.0.0.CR1-osx-x86_64.exe

when using gradle or macOS.

Workaround:

In build.gradle:

plugins {
    id 'com.google.protobuf' version '0.8.13'
}

apply plugin: 'com.google.protobuf'
def vertxVersion = '4.0.0.CR1'

dependencies {
    implementation(group: 'io.vertx', name: 'vertx-grpc', version: vertxVersion) {
        exclude group: 'com.google.code.gson', module: 'gson'
    }
}

protobuf {
    protoc {
        artifact = 'com.google.protobuf:protoc:3.13.0'
    }
    plugins {
        grpc_java {
            artifact = 'io.grpc:protoc-gen-grpc-java:1.33.1'
        }
        grpc_java_vertx {
            path = project.projectDir.absolutePath + "/bin/grpc_java_plugin"
        }
    }
    generateProtoTasks {
        all()*.builtins {
            java {}
        }
        all()*.plugins {
            grpc_java {
                outputSubDir = "java"
            }
            grpc_java_vertx {
                outputSubDir = "java"
            }
        }
    }
}

Observe you will need to create an executable at ./bin/grpc_java_plugin, use the following contents for this file:

File ./bin/grpc_java_plugin:

#!/usr/bin/env bash
read -r -d '' SCRIPT <<EOF
mvn dependency:get -DremoteRepositories=https://repo1.maven.org/maven2/ -DgroupId=io.vertx -DartifactId=vertx-grpc-protoc-plugin -Dversion=4.0.0.CR1 -Dtransitive=true > /dev/null
MVN_REPO=\$(mvn help:evaluate -Dexpression=settings.localRepository -q -DforceStdout)
CLASSPATH=\$(find \$MVN_REPO -type f -path '*.jar' | tr '\\n' ':')
java -cp "\$CLASSPATH" io.vertx.grpc.protoc.plugin.VertxGrpcGenerator
EOF

docker run -v "$(pwd)":/defs -w "/defs" --rm -i maven:latest bash -c "${SCRIPT}"

To mark it executable, chmod +x ./bin/grpc_java_plugin. Observe it uses docker's maven image to download and run the generator JAR.

The io.grpc.ServerInterceptor.interceptCall() has a synchronized signature and is called in event-loop thread. I see two ways to improve this behavior:

• wrap interceptCall() to call it on vertx worker (see the proposed prototype, it is ready for PR)
• introduce AsyncServerInterceptor

/cc @pmlopes
/cc @vietj

VertxServer uses ContextImpl which has a package visibility.
see https://vertx.ci.cloudbees.com/view/vert.x-3/job/vert.x3-grpc/45/console

For instance:

Feb 14, 2017 11:08:53 PM io.grpc.internal.SerializingExecutor$TaskRunner run
SEVERE: Exception while executing runnable io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed@6668e779
java.lang.NullPointerException
	at io.vertx.grpc.impl.GrpcReadStreamImpl$1.onCompleted(GrpcReadStreamImpl.java:69)
	at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:390)
	at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:422)

Background

Say a piece of proto code:

import "google/protobuf/wrappers.proto";

service UserEndpoint {
  rpc GetPasswordByEmail(google.protobuf.StringValue) returns (google.protobuf.StringValue);
}

Using the latest gradle plugins:

protobuf {
  protoc {
    artifact = 'com.google.protobuf:protoc:3.11.1'
  }
  plugins {
    grpc {
      artifact = "io.vertx:protoc-gen-grpc-java:1.25.0"
    }
  }
  generateProtoTasks {
    all().each { task ->
      task.plugins {
        grpc {}
      }
    }
  }
}

The generated service:

public static abstract class UserEndpointImplBase implements io.grpc.BindableService {

    /**
     */
    public void getPasswordByEmail(com.google.protobuf.StringValue request,
        io.grpc.stub.StreamObserver<com.google.protobuf.StringValue> responseObserver) {
      asyncUnimplementedUnaryCall(getGetPasswordByEmailMethod(), responseObserver);
    }

Question

The generated service function is using com.google.protobuf.StringValue rather than java.lang.String. Is this a feature?