camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ferraro (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CAMEL-11236) camel-grpc - improve streaming capabilities to bridge reactive streams
Date Mon, 08 May 2017 11:22:04 GMT
Nicola Ferraro created CAMEL-11236:
--------------------------------------

             Summary: 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.3.15#6346)

Mime
View raw message