<div dir="ltr"><div class="gmail_default" style="font-size:large">Stuart,</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large"> 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).</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Andy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 12, 2017 at 3:48 AM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>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.</div><div><br></div><div>My proof of concept uses an Undertow based port of GRPC [2] and basically works as follows:</div><div><br></div><div>- At deployment time Jandex is used to find all non-abstract classes that implement io.grpc.BindableService</div><div>- 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().</div><div>- An instance/proxy is created using the ComponentRegistry to do the creation, and the generated proxy delegates all incoming calls to this instance</div><div>- At runtime any incoming HTTP/2 requests with a type of application/grpc are intercepted, and passed through this newly created proxy.</div><div><br></div><div>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.</div><div><br></div><div>Note that this is a very early stage POC, and lots of stuff is missing (most notably security). </div><div><br></div><div>Before I go to much further though I though that I should get some feedback, e.g.</div><div><br></div><div>- 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.</div><div>- Is the current implementation the best way of actually registering GRPC services, or should we require some kind of defining annotation</div><div>- What security mechanisms should we support? Out of the box standard GRPC is fairly limited</div><div>- 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. </div><div><br></div><div>Stuart</div><div><br></div><div>[1] <a>https://github.com/<wbr>stuartwdouglas/wildfly/tree/<wbr>grpc</a></div><div>[2] <a>https://github.com/<wbr>stuartwdouglas/undertow-grpc</a></div></div>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a>wildfly-dev@lists.jboss.org</a><br>
<a rel="noreferrer">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></blockquote></div></div></div>
<br>______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><font size="4">Andrig (Andy) T. Miller<br></font></div><font size="4">Global Platform Director, Middleware<br></font></div><font size="4">Red Hat, Inc.</font><br></div></div></div></div>
</div>