[
https://issues.apache.org/jira/browse/CAMEL-11236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052034#comment-16052034
]
ASF GitHub Bot commented on CAMEL-11236:
----------------------------------------
Github user nicolaferraro closed the pull request at:
https://github.com/apache/camel/pull/1763
> camel-grpc - improve streaming capabilities to bridge reactive streams
> ----------------------------------------------------------------------
>
> Key: CAMEL-11236
> URL: https://issues.apache.org/jira/browse/CAMEL-11236
> Project: Camel
> Issue Type: New Feature
> Components: camel-grpc
> Reporter: Nicola Ferraro
> Assignee: Nicola Ferraro
> Fix For: 2.20.0
>
>
> We have grpc producer-only capabilities at the moment. After the
> implementation of the grpc consumer side, it would be interesting to
> investigate how we can make it easy to use grpc as transport for reactive
> streams across network in different JVMs.
> Something like this from the sending side:
> {code}
> from("reactive-streams:datasource")
> to("grpc:my.Data?mehod=stream&host=xxx&port=yyy");
> {code}
> And this from the receiving side:
> {code}
> from("grpc:my.Data?mehod=stream&port=yyy")
> to("reactive-streams:datasink");
> {code}
> Then from a RX implementation one can send a stream of data to *datasource*
> and receive it using the *datasink* stream in the other JVM.
> We can leverage the streaming capabilities of grpc (payloads and return types
> can be "streams" of data).
> Grpc has also an internal way to handle backpressure using a bounded internal
> buffer. We can "bridge" the grpc backpressure mechanism to the
> reactive-streams one, to have a proper flow control.
> We should give to reactive-streams subscriptions an identifier to distinguish
> between a new method call or a continuation of the current stream (something
> like this is reported in CAMEL-11140).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
