[wildfly-dev] GRPC subsystem proof of concept

[Stuart Douglas]

Not without writing a new protobuf compiler, the compiler does not provide
any places to hook into the registration process, the only way I could
manage to do it was to subclass the generated class with a proxy. Protobuf
generates a fair bit of code for each class anyway, so I don't think the
proxy will add much percentage wise.

Stuart

On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <anmiller at redhat.com> wrote:

> Stuart,
>
>       Because I have memory footprint on the brain, pretty much all the
> time now, I wonder if you can change your approach in a way that would
> lessen MetaSpace usage.  MetaSpace usage is usually the second largest
> memory hog in Wildfly/EAP, and under certain circumstances it can be larger
> than heap, when the right JVM settings are used to control heap usage (part
> of my presentation in 30 minutes).
>
> Andy
>
> On Tue, Dec 12, 2017 at 3:48 AM, Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> On the security question, if we are interested in pursuing this we will
>> get an analysis document started to look at the options we have for
>> integration with our security implementation.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>>
>> On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <stuart.w.douglas at gmail.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I have done up a proof of concept of GRPC support in Wildfly, which can
>>> be found at [1]. GRPC is an RPC protocol designed by Google, that allows
>>> for easy cross platform invocations.
>>>
>>> My proof of concept uses an Undertow based port of GRPC [2] and
>>> basically works as follows:
>>>
>>> - At deployment time Jandex is used to find all non-abstract classes
>>> that implement io.grpc.BindableService
>>> - I scan the class hierarchy of these classes to find the protobuf
>>> generated base class, and create a subclass of this class using
>>> ProxyFactory, overriding every method except bindService().
>>> - An instance/proxy is created using the ComponentRegistry to do the
>>> creation, and the generated proxy delegates all incoming calls to this
>>> instance
>>> - At runtime any incoming HTTP/2 requests with a type of
>>> application/grpc are intercepted, and passed through this newly created
>>> proxy.
>>>
>>> Basically this means that all you need to do as an application developer
>>> is define your GRPC endpoints using protobuf, implement the classes
>>> generated by the protobuf compiler and then include them in your
>>> application, and Wildfly will do the rest. CDI and EJB annotations on your
>>> GRPC services should work as normal, for example if you put @Stateless on
>>> an endpoint it should work as expected with a SFSB handling all invocations.
>>>
>>> Note that this is a very early stage POC, and lots of stuff is missing
>>> (most notably security).
>>>
>>> Before I go to much further though I though that I should get some
>>> feedback, e.g.
>>>
>>> - Do we actually want this? I am not sure how much interest there is,
>>> but it seems like GRPC could be very useful in a polyglot microservice
>>> environment.
>>> - Is the current implementation the best way of actually registering
>>> GRPC services, or should we require some kind of defining annotation
>>> - What security mechanisms should we support? Out of the box standard
>>> GRPC is fairly limited
>>> - What do we do about transactions? I am leaning towards not supporting
>>> them over GRPC, as we already have solutions for Java invocation in the
>>> form of our EJB protocol, and I think non-Java clients are unlikely to want
>>> to use this.
>>>
>>> Stuart
>>>
>>> [1] https://github.com/stuartwdouglas/wildfly/tree/grpc
>>> [2] https://github.com/stuartwdouglas/undertow-grpc
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171213/96447fa0/attachment.html