I can add to a couple of questions.
Re: > "Do gRPC clients honor DNS TTL ?"
gRPC clients don't look at TTL's at all. In C++, a gRPC client channel will
request it's DNS resolver to re-resolve when it determines that it has
reached "transient failure" state. The details of when exactly it
Commented on the PR, thanks for bringing this to attention. There are a
couple of different issues here, looking in to it
On Thursday, September 27, 2018 at 3:21:49 PM UTC-7, Matt Todd wrote:
>
> Thanks for following up! My apologies for not getting back to this sooner.
>
> I've opened
Re: context
I'm not clear on what the bug is at this point, or if there is one. If I
understand, the issues encountered here were while attempting to reproduce
a suspected bug?
Re: SETTING UP LOCAL DEVELOPMENT
I'm actually surprised that your invocation of "python
The way in that the server response stream is is sent with a "pull API"
rather than "push API" indeed prevents e.g. detecting failed writes from
the application's stream handler. Is is possible to continuously read from
the "requests from client stream" enumerable on the server - that "requests
Adding jiangtao@ for thoughts on this (providing an option to allow call
credentials over an insecure channel)
On Monday, March 26, 2018 at 12:14:03 PM UTC-7, Colin Morelli wrote:
>
> Hey group,
>
> I've seen discussions before about CallCredentials and their ability to be
> used on insecure
ut not yet delivered calls.
>>
>> Should we additionally account for this? If yes, how? Is it polled? Is
>> there a callback model?
>>
>> On Thu, Jan 18, 2018, 8:56 PM apolcyn via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>>&
; What about metadata?
>
> Server memory can change drastically over time since it also maintains a
> list of channels and incoming but not yet delivered calls.
>
> Should we additionally account for this? If yes, how? Is it polled? Is
> there a callback model?
>
&g
I just moved this discussion
to https://groups.google.com/forum/#!forum/grpc-io. While this might be
useful to Java and Go, I'll the scope of this proposal to C-core and
wrapped languages, to focus on the external-memory and garbage collection
interaction issue.
On Thursday, January 18, 2018
Discussion of https://github.com/grpc/proposal/pull/55
this thread
supersedes https://groups.google.com/forum/#!topic/grpc-io/FPoXprcT0d4
--
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
https://github.com/grpc/proposal/pull/55
On Thursday, January 18, 2018 at 8:29:06 PM UTC-8, apo...@google.com wrote:
>
> This is a thread to discuss the gRFC proposal.
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group
This is to follow a discussion of the grpc-ruby API addition
in https://github.com/grpc/proposal/pull/54
--
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
choonk@ that API exists in the C-core but is not currently exposed by the
C# wrapper. If this functionality is still wanted though, I suggest filing
a feature request issue in github or a pull request.
On Wednesday, January 10, 2018 at 6:42:47 PM UTC-8, choonk...@gmail.com
wrote:
>
> Is it
Hi,
There is an example of using the "channel_override" for stub creation in
these tests:
https://github.com/grpc/grpc/blob/master/src/ruby/spec/generic/rpc_server_spec.rb#L318.
And a brief example of creating a GRPC::Core::Channel with credentials is
in
Also, one more important note on tests:
While the grpc/ruby unit tests are helpful for API conformance, a minimal
implementation would still need to be passing with the grpc-wide interop
test suite.
(see script
in
https://github.com/grpc/grpc/blob/master/tools/run_tests/run_interop_tests.py,
Sorry for the delay here.
Indeed as is in ruby, the only exposed client certificate request types are
GRPC_SSL_REQUEST_AND_REQUIRE_CLIENT_CERTIFICATE_AND_VERIFY
and GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE.
(This is exposed through the final parameter of the ServerCredentials
constructor,
As has been noted before, I think this would be possible by doing a pure
implementation, wrapping the java client, or with a JNI wrapper over the
C-core (these implementations probably end up relatively different from
C-wrapping grpc-ruby).
Actually one thing hasn't been noted yet: If only a
This looks like an issue that has been seen in grpc-go earlier. What types
of calls are these - unary? or streaming?
Indeed for unary calls, each call is currently flushing writes after
sending headers and status for each call. The message portions of unary and
streaming calls (split up into
17 matches
Mail list logo
