[
https://issues.apache.org/jira/browse/CAMEL-11236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050592#comment-16050592
]
ASF GitHub Bot commented on CAMEL-11236:
----------------------------------------
GitHub user nicolaferraro opened a pull request:
https://github.com/apache/camel/pull/1763
CAMEL-11236: added gRPC streaming producer strategy
Added a way to keep a gRPC stream open towards a remote server and send all
exchanges inside that stream, routing all responses to another endpoint (usage
added in the doc).
It may be improved (error handling and backpressure), but I think it's ok
as first pass.
@dmvolod can you have a look at it?
I've also renamed "processing strategy" (it's a new field in 2.20) to
"consumer strategy" in order to introduce a "producer strategy" (RPC /
STREAMING).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/nicolaferraro/camel CAMEL-11236
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1763.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1763
----
commit f9e0279576cc0b1d2809c2731c18214be757629a
Author: Nicola Ferraro <[email protected]>
Date: 2017-06-12T10:20:01Z
CAMEL-11236: added gRPC streaming producer strategy
----
> 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)
