GRPC subsystem proof of concept

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

GRPC subsystem proof of concept

Stuart Douglas
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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

Darran Lofthouse
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 <[hidden email]> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

Andrig Miller
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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

Sanne Grinovero
On 12 December 2017 at 22:24, Stuart Douglas <[hidden email]> wrote:
> 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.

The Google tooling for ProtoBuf expect you to use code generation
depending on the schema, but it's not the only toolset available.

Infinispan also uses ProtoBuf for encoding of client/server data yet
forcing people to use code generation seemed too annoying, so they use
ProtoStream:
 - https://github.com/infinispan/protostream

In turn this is based on Square's Protoparser. I have no idea if it's
more efficient, but it's possible as the alternative feels less
verbose than the codegeneration approach; it's certainly more
convenient.

Hibernate OGM has a "dialect" able to encode JPA storage operations
into Infinispan Remote calls using a combination of the above
libraries; in terms of usage people just deploy JPA annotated pojos on
WildFly and the necessary infrastructure is generated via an internal
metamodel and a chain of method references: no proxies nor code
generation.

Sanne

>
> Stuart
>
> On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <[hidden email]> 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
>> <[hidden email]> 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 <[hidden email]>
>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> --
>> Andrig (Andy) T. Miller
>> Global Platform Director, Middleware
>> Red Hat, Inc.
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

Rostislav Svoboda
Hi.

tl;dr: I'm not sure WF is the right place for GRPC integration

1) footprint
  io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using version 1.5.0)

2) speed of development
  version 1.5.0 in July
  version 1.8.0 in November
  speed itself is not the main problem, point 3) is more concerning

3) changes in minor releases
I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got compilation failure with 18 errors

Every minor (looked at 1.5.0+) has one of the following mentioned in https://github.com/grpc/grpc-java/releases 
  API Changes
  Incompatible Changes
  Behavior changes
  Important Changes

4) cncf.io
Looking at https://www.cncf.io/ my impression is that direct support in OpenShift or SWARM-627 would make sense.

5) yet another integration/rpc solution
We have Corba / EJB, JAX-WS, JAX-RS, JMS.
Do we want / need it grpc in WF? What would be the advantage of this integration?


I know I sound to pessimistic, feel free to turn me into grpc-optimist ;)

Rostislav

----- Original Message -----

> On 12 December 2017 at 22:24, Stuart Douglas <[hidden email]>
> wrote:
> > 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.
>
> The Google tooling for ProtoBuf expect you to use code generation
> depending on the schema, but it's not the only toolset available.
>
> Infinispan also uses ProtoBuf for encoding of client/server data yet
> forcing people to use code generation seemed too annoying, so they use
> ProtoStream:
>  - https://github.com/infinispan/protostream
>
> In turn this is based on Square's Protoparser. I have no idea if it's
> more efficient, but it's possible as the alternative feels less
> verbose than the codegeneration approach; it's certainly more
> convenient.
>
> Hibernate OGM has a "dialect" able to encode JPA storage operations
> into Infinispan Remote calls using a combination of the above
> libraries; in terms of usage people just deploy JPA annotated pojos on
> WildFly and the necessary infrastructure is generated via an internal
> metamodel and a chain of method references: no proxies nor code
> generation.
>
> Sanne
>
> >
> > Stuart
> >
> > On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <[hidden email]> 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
> >> <[hidden email]> 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 <[hidden email]>
> >>> 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
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> [hidden email]
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >>
> >> --
> >> Andrig (Andy) T. Miller
> >> Global Platform Director, Middleware
> >> Red Hat, Inc.
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

Stuart Douglas


On Tue, Dec 19, 2017 at 3:20 AM, Rostislav Svoboda <[hidden email]> wrote:
Hi.

tl;dr: I'm not sure WF is the right place for GRPC integration

1) footprint
  io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using version 1.5.0)

Not much we can do about that, but it won't be loaded unless you are using it.
 

2) speed of development
  version 1.5.0 in July
  version 1.8.0 in November
  speed itself is not the main problem, point 3) is more concerning

3) changes in minor releases
I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got compilation failure with 18 errors

Yea, that is somewhat annoying. I don't think it affects the wire protocol though, just the Java SPI (even though they provide an integration SPI I don't think anyone has really tried to use it before, and provide a transport outside what is already provided in the distribution).
 

Every minor (looked at 1.5.0+) has one of the following mentioned in https://github.com/grpc/grpc-java/releases
  API Changes
  Incompatible Changes
  Behavior changes
  Important Changes

4) cncf.io
Looking at https://www.cncf.io/ my impression is that direct support in OpenShift or SWARM-627 would make sense.

I think that once we have a provisioning solution there is no reason why we can't provide things like this to work in both swarm and WildFly. 
 

5) yet another integration/rpc solution
We have Corba / EJB, JAX-WS, JAX-RS, JMS.
Do we want / need it grpc in WF? What would be the advantage of this integration?

The main advantage is that it is a binary cross platform solution that provides strong typing (JAX-RS/REST is also cross platform, but generally you don't get the same strong typing guarantees and it is more verbose on the wire).



I know I sound to pessimistic, feel free to turn me into grpc-optimist ;)

Fair enough. I posted this to try and gauge interest to see if this is worth pursuing, we can't do everything so unless there is interest it probably won't go past the proof of concept stage.

Stuart
 

Rostislav

----- Original Message -----
> On 12 December 2017 at 22:24, Stuart Douglas <[hidden email]>
> wrote:
> > 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.
>
> The Google tooling for ProtoBuf expect you to use code generation
> depending on the schema, but it's not the only toolset available.
>
> Infinispan also uses ProtoBuf for encoding of client/server data yet
> forcing people to use code generation seemed too annoying, so they use
> ProtoStream:
>  - https://github.com/infinispan/protostream
>
> In turn this is based on Square's Protoparser. I have no idea if it's
> more efficient, but it's possible as the alternative feels less
> verbose than the codegeneration approach; it's certainly more
> convenient.
>
> Hibernate OGM has a "dialect" able to encode JPA storage operations
> into Infinispan Remote calls using a combination of the above
> libraries; in terms of usage people just deploy JPA annotated pojos on
> WildFly and the necessary infrastructure is generated via an internal
> metamodel and a chain of method references: no proxies nor code
> generation.
>
> Sanne
>
> >
> > Stuart
> >
> > On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <[hidden email]> 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
> >> <[hidden email]> 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 <[hidden email]>
> >>> 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
> >>>> [hidden email]
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> [hidden email]
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >>
> >> --
> >> Andrig (Andy) T. Miller
> >> Global Platform Director, Middleware
> >> Red Hat, Inc.
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

jtgreene
Administrator

On Dec 18, 2017, at 4:53 PM, Stuart Douglas <[hidden email]> wrote:



On Tue, Dec 19, 2017 at 3:20 AM, Rostislav Svoboda <[hidden email]> wrote:
Hi.

tl;dr: I'm not sure WF is the right place for GRPC integration

1) footprint
  io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using version 1.5.0)

Not much we can do about that, but it won’t be loaded unless you are using it.

Also once we have provisioning then it could be easily removed and/or kept as an optional feature.
 

2) speed of development
  version 1.5.0 in July
  version 1.8.0 in November
  speed itself is not the main problem, point 3) is more concerning

3) changes in minor releases
I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got compilation failure with 18 errors

Yea, that is somewhat annoying. I don’t think it affects the wire protocol though, just the Java SPI (even though they provide an integration SPI I don't think anyone has really tried to use it before, and provide a transport outside what is already provided in the distribution).

Even with the SPI  it looks fairly reasonable: going through the history it appears they deprecate stuff first, then many releases later remove the deprecated methods. Of course I might have missed something.

-Jason



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

jtgreene
Administrator
In reply to this post by Stuart Douglas

On Dec 18, 2017, at 4:53 PM, Stuart Douglas <[hidden email]> wrote:



On Tue, Dec 19, 2017 at 3:20 AM, Rostislav Svoboda <[hidden email]> wrote:
Hi.

tl;dr: I'm not sure WF is the right place for GRPC integration

1) footprint
  io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using version 1.5.0)

Not much we can do about that, but it won’t be loaded unless you are using it.

Also once we have provisioning then it could be easily removed and/or kept as an optional feature.
 

2) speed of development
  version 1.5.0 in July
  version 1.8.0 in November
  speed itself is not the main problem, point 3) is more concerning

3) changes in minor releases
I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got compilation failure with 18 errors

Yea, that is somewhat annoying. I don’t think it affects the wire protocol though, just the Java SPI (even though they provide an integration SPI I don't think anyone has really tried to use it before, and provide a transport outside what is already provided in the distribution).

Even with the SPI  it looks fairly reasonable: going through the history it appears they deprecate stuff first, then many releases later remove the deprecated methods. Of course I might have missed something.

-Jason



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRPC subsystem proof of concept

Rostislav Svoboda

> > 1) footprint
> >   io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using
> >   version 1.5.0)
> >
> > Not much we can do about that, but it won’t be loaded unless you are using
> > it.
>
> Also once we have provisioning then it could be easily removed and/or kept as
> an optional feature.

Side note to provisioning:
  We could have some kind of EPEL repository to indicate that feature packs available there are optional / evolving_quickly / kind_of_PoC


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev