[grpc-java] useInputStreamMessages in client interceptors?

[thas....@gmail.com]

I am using https://github.com/grpc/grpc-java/blob/45085c3ce40f37c39e2fc630f2d06f052064ee93/core/src/main/java/io/grpc/ServerInterceptors.java#L138 on my server, and there doesn't seem to be a client-side equivalent to this.

I would like to override the onMessage(RespT resp) in my client-side interceptor  (SimpleForwardingClientCallListener) to work with an input stream rather than the grpc parsed request object. This is because i am sending some additional bytes in the input stream from my server and am going to do some additional work, before I manually parse the object and send to the handler. 

Anyone have alternative suggestions to this?

Thanks!

[William Thurston]

I had contributed the server side of this originally, and the intended use was for caching purposes where a server could receive and return pure bytes from a cache driven by headers or something without needing to pay serialization costs. Given that original motivation, I didn't see value in doing the same thing client side where a cache query/response would be best served as an actual Java object, so I never wrote it :)

Have you considered using headers instead for the case you're looking at?  I believe there was also recently added support for proxy related stuff at the front of a stream that gets handled at the Netty layer.  Maybe one of those alternatives works?

William Thurston

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/e03a3c33-f6bd-4ce1-ab98-65a9609ac455%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thas Himalayaratnam]

Hey William!

So headers won't work for me in this case because I need to do this per message in a bidi stream call. And headers are only sent/received at the start of the call, not on the individual messages from observer.onNext(request). 

With regards to the proxy related stuff, do you mind pointing me in a useful direction to get started? 

Thanks again.

On Mon, Oct 2, 2017 at 3:57 PM, William Thurston <m...@williamthurston.com> wrote:

I had contributed the server side of this originally, and the intended use was for caching purposes where a server could receive and return pure bytes from a cache driven by headers or something without needing to pay serialization costs. Given that original motivation, I didn't see value in doing the same thing client side where a cache query/response would be best served as an actual Java object, so I never wrote it :)

Have you considered using headers instead for the case you're looking at?  I believe there was also recently added support for proxy related stuff at the front of a stream that gets handled at the Netty layer.  Maybe one of those alternatives works?

William Thurston

On Oct 2, 2017, at 3:49 PM, "thas....@gmail.com" <thas....@gmail.com> wrote:

I am using https://github.com/grpc/grpc-java/blob/45085c3ce40f37c39e2fc630f2d06f052064ee93/core/src/main/java/io/grpc/ServerInterceptors.java#L138 on my server, and there doesn't seem to be a client-side equivalent to this.

I would like to override the onMessage(RespT resp) in my client-side interceptor  (SimpleForwardingClientCallListener) to work with an input stream rather than the grpc parsed request object. This is because i am sending some additional bytes in the input stream from my server and am going to do some additional work, before I manually parse the object and send to the handler. 

Anyone have alternative suggestions to this?

Thanks!

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/e03a3c33-f6bd-4ce1-ab98-65a9609ac455%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Thas

[William Thurston]

I found a pull request at www.github.com/grpc/grpc-java/pull/2545 but this is per connection and not per message I believe, so may still not work in your case. 

William Thurston

[Thas Himalayaratnam]

Ah rats. :sadpanda:

--

Regards,

Thas

[Eric Anderson]

Server-side is actually a bigger pain than client-side, but also the server-side-style approach won't work on client-side.

ClientCall<ReqT, RespT> interceptCall(

    MethodDescriptor<ReqT, RespT> method, CallOptions callOptions, Channel next) {

  MethodDescriptor isMethod = method.toBuilder()

      .setRequestMarshaller(myInputStreamMarshaller)

      .setResponseMarshaller(myInputStreamMarshaller)

      .build();

  ClientCall<InputStream, InputStream> cc = next.newCall(isMethod, callOptions);

  // wrap the call to your liking.

  // do things like method.streamRequest(req) to convert between messages and bytes

}

The MyInputStreamMarshaller itself is trivial; use InputStream as the type T and just return the argument to each method.

--

[thas....@gmail.com]

Worked like a charm! Thank you Eric :D

On Thursday, October 5, 2017 at 1:35:56 PM UTC-7, Eric Anderson wrote:

Server-side is actually a bigger pain than client-side, but also the server-side-style approach won't work on client-side.

ClientCall<ReqT, RespT> interceptCall(

    MethodDescriptor<ReqT, RespT> method, CallOptions callOptions, Channel next) {

  MethodDescriptor isMethod = method.toBuilder()

      .setRequestMarshaller(myInputStreamMarshaller)

      .setResponseMarshaller(myInputStreamMarshaller)

      .build();

  ClientCall<InputStream, InputStream> cc = next.newCall(isMethod, callOptions);

  // wrap the call to your liking.

  // do things like method.streamRequest(req) to convert between messages and bytes

}

The MyInputStreamMarshaller itself is trivial; use InputStream as the type T and just return the argument to each method.

On Mon, Oct 2, 2017 at 3:49 PM, <thas....@gmail.com> wrote:

I am using https://github.com/grpc/grpc-java/blob/45085c3ce40f37c39e2fc630f2d06f052064ee93/core/src/main/java/io/grpc/ServerInterceptors.java#L138 on my server, and there doesn't seem to be a client-side equivalent to this.

I would like to override the onMessage(RespT resp) in my client-side interceptor  (SimpleForwardingClientCallListener) to work with an input stream rather than the grpc parsed request object. This is because i am sending some additional bytes in the input stream from my server and am going to do some additional work, before I manually parse the object and send to the handler. 

Anyone have alternative suggestions to this?

Thanks!

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.