[grpc-io] Support Croutine based async grpc server cpp++

[Lei Wang]

It is much easier for us to implement coroutine in python, java, and 
machines with VM so that we can monitor the memory address where we are 
executing.

in grpc c++, we recommend to use glib ucontext, which is widely employed by 
our c++ developers and we could use it stop, consume threads for c++. By 
deveoping Future so and wrapped async io event, we can jump back to memory 
address where we wait for a task done.

I would not recommend implementing async server completion queue callback 
because it will be eventually replaced by a solution first released as the 
coutine version async grpc.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/63f1d8b4-e7df-4d54-9ab7-35e7729fac8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Future of GRPC-LB

['Srini Polavarapu' via grpc.io]

Please expect a post on this soon. It will have the details you are looking 
for but a detailed gRFC will come later. We can continue discussion on that 
post.

Thanks. 

On Monday, February 25, 2019 at 12:39:27 PM UTC-8, blazej...@gmail.com 
wrote:
>
> The thing is, that we have implemented a server-side LB which speaks 
> grpclb and this whole machinery seems to work pretty well - so we wanted to 
> deploy it any day now. What is more, we wanted to make it open-source and 
> we had some ideas to develop it further. So, could you be a little bit more 
> specific on those topics?
>
> 1) How long (approximately) will grpclb be still supported? It would be 
> fair to have some time to migrate to the new solution.
> 2) How will this new solution look like? I can't find any information 
> about it, either on grpc's GitHub (no docs) or on this group. When I try to 
> google "grpc load balancing" I still hit docs about grpclb.
> 3) Is this XDS solution going to work out-of-the-box, or, similarly to 
> grpclb we will have to implement some part on our own (I mean, in grpclb we 
> had to implement server-side of the protocol - how does it work with XDS)?
>
> W dniu poniedziałek, 25 lutego 2019 19:19:48 UTC+1 użytkownik Carl 
> Mastrangelo napisał:
>>
>> Like Penn said, you can turn it on (it's experimental), but will 
>> eventually be replaced.  The flag itself is pretty simple, but the rest of 
>> the machinery needs to be set up properly for it to work.  We (gRPC 
>> maintainers) are not comfortable supporting this yet, hence the extra 
>> effort to turn it on.   The gRPCLB Load Balancer is experimental, so we 
>> will likely remove it at some point.  We will give a notice in one of the 
>> upcoming releases that it is deprecated, and then remove it the release 
>> after.   Since the replacement isn't yet ready, it has not been removed.
>>
>> Sorry to be so non-committal, but it seems like XDS is a better long term 
>> LB solution, and we don't want to support two competing implementations.
>>
>> On Saturday, February 23, 2019 at 12:48:43 AM UTC-8, blazej...@gmail.com 
>> wrote:
>>>
>>> And what about SRV records lookup: now I have to set this flag:
>>>
>>> io.grpc.internal.DnsNameResolverProvider.enable_grpclb

>>>
>>> to true, and there was a commit some time ago which enabled it by 
>>> default: 
>>> https://github.com/grpc/grpc-java/commit/c729a0f76b244da9f4aebc40896b2fb891d1b5c4
>>>  
>>> and now it has been reverted: 
>>> https://github.com/grpc/grpc-java/pull/5232 - how it is eventually 
>>> going to be? 
>>>
>>>
>>> W dniu piątek, 22 lutego 2019 21:16:54 UTC+1 użytkownik Penn (Dapeng) 
>>> Zhang napisał:

 Neither grpclb nor xds will be enabled by default, grpclb need be 
 explicitly enabled by a service config or a ManagedChannelBuilder option, 
 and xds need be explicitly enabled by a service config.  Grpclb will 
 eventually be replaced by xds based solution in the future, but the 
 grpc-grpclb  maven 
 artifact will stay and work for a long time (for as many new releases as 
 possible). When grpclb is not available for a new grpc release, your 
 client 
 can still automatically switch to a fallback loadbalancer (pick_first).

 On Friday, February 22, 2019 at 8:52:16 AM UTC-8, blazej...@gmail.com 
 wrote:
>
> What is the status of GRPCLB - are there any plans to enable it by 
> default and finish the experimental stage (we want to start using it in 
> production), or opposite, you plan to abandon it? I am confused, because 
> I've read this PR: https://github.com/grpc/grpc-java/pull/5232:
>
> SRV has not yet been enabled in a release. 
>>
>> *Since work is rapidlyunderway to replace GRPC-LB with a service 
>> config+XDS-based solution,there's now thoughts that we won't ever enable 
>> grpclb by default* (but
>> may allow it to be automatically enabled when using 
>> GoogleDefaultChannel
>> or similar). Since things are being worked out, disable it.
>
>
> It will be really helpful to us to know, what is the plan for it :)
>


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/56690c2c-0e9a-47bf-832b-28afe9bf8165%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: grpc_insecure_channel_create DNS and connection expectations

[Pau Freixes]

Thanks, that is was I suspect.
IMO the docstring in the code for the `grpc_insecure_channel_create`
must be modified , now it can lead to some misunderstanding

On Wed, Feb 27, 2019 at 7:48 PM yashkt via grpc.io
 wrote:
>
> I am speaking from a Core/C++ perspective. Simply creating a channel does not 
> lead to connection attempts. It's the first RPC or an explicit connect 
> request that triggers it.
> To explicitly connect - 
> https://github.com/grpc/grpc/blob/b0b35b03a7eb775b570c3e186926928641a77690/include/grpcpp/channel.h#L53
>
> On Sunday, February 24, 2019 at 10:04:06 AM UTC-8, Pau Freixes wrote:
>>
>> Hi,
>>
>> Reading the source code of `grpc_insecure_channel_create` [1] seems
>> that this function must trigger in some way the DNS query for the
>> target and also the first connection handshake asynchronously
>>
>> Executing one of the Python examples seems that the DNS resolution and
>> the connection are not really done until at least one request is
>> executed [2].
>>
>> Am I missing something?
>>
>> If not, is this is the default implementation? So other languages like
>> C++, Java, Node.js are using the same pattern?
>>
>> Does the API provide a way of making the connection step explicitly?
>>
>> [1] 
>> https://github.com/grpc/grpc/blob/8860eb34ab9183589a039a36a6e10a74b440c501/src/core/ext/transport/chttp2/client/insecure/channel_create.cc#L82
>> [2] 
>> https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client.py#L31
>>
>> --
>> --pau
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to grpc-io@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/8943b3cf-7bf9-46a9-876e-63dc374be0c3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
--pau

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/CA%2BULCcFrmLUki_tSQOyx0bqPRXAN8Ugitx_%3Dt%3De7L3WR%2BG3kcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Restarting C++ server after shutdown?

[Antoine Pitrou]

But calling Shutdown() is the only way to stop the server, right?

Regards

Antoine.


On Wed, 27 Feb 2019 10:58:07 -0800 (PST)
"yashkt via grpc.io"  wrote:
> I suggest not shutting down the server too early if there is a possibility 
> of using it in the future.
> 
> On Wednesday, February 27, 2019 at 4:55:05 AM UTC-8, Antoine Pitrou wrote:
> >
> >
> > Hello, 
> >
> > If I call the Shutdown() method on a grpc::Server instance, is it 
> > possible to start serving again without creating a new Server? 
> > It seems that the Wait() method will return immediately if I call it 
> > again. 
> >
> > Use case: I have a signal handler that will shutdown the server. 
> > Then, when Wait() returns, I run any Python signal handlers and would 
> > like to restart if they didn't raise an exception. 
> >
> > Regards 
> >
> > Antoine. 
> >
> >
> >  
> 



-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/20190227211206.0d889b12%40fsol.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRPC-Core Release 1.19.0

['Srini Polavarapu' via grpc.io]

This is the 1.19.0 (gold) release announcement for gRPC-Core and the 
wrapped languages C++, C#, Objective-C, Python, PHP and Ruby. Latest 
release notes are here .

This release contains refinements, improvements, and bug fixes, with 
highlights listed below.
Core
   
   - Fix c-ares on Windows "DNS resolution failure" triggered by logging. (
   #18092 )
   - Disable c-ares on Android (Backport #18046 
   ). (#18050 
   )
   - Ignore reserved bit in WINDOW_UPDATE frame. (#17950 
   )
   - Set c-ares as the default resolver. (#17897 
   )
   - Add period at end of metadata.google.internal to prevent unnecessary 
   DNS lookups. (#17598 )
   - Decrease verbosity of ALTS platform check to avoid a spam log message. 
   (#17874 )
   - Fix windows localhost address sorting bug. (#17790 
   )
   - Re-enable c-ares as the default resolver; but don't turn on SRV 
   queries. (#17723 )
   - Remove filters from subchannel args. (#17629 
   )

C++
   
   - Register for cq avalanching when interceptors are going to be run. (
   #17806 )
   - Add a caching interceptor to the keyvaluestore example. (#17689 
   )
   - Enable per-channel subchannel pool. (#17513 
   )
   - Fix build with bazel 0.21. (#17684 
   )
   - Switch the default DNS resolver from native to c-ares. (#16862 
   )
   - Modifying semantics for GetSendMessage and GetSerializedSendMessage. 
   Also adding ModifySendMessage. (#17630 
   )
   - Add interceptor methods to fail recv msg for hijacked rpcs and set 
   recv message to nullptr on failure. (#17179 
   )
   - Add interceptor method to fail hijacked send messages and get status 
   on POST_SEND_MESSAGE. (#17220 )
   - New Experimental Interception API - GetSendMessage and 
   GetSerializedSendMessage. (#17609 
   )

C#
   
   - Upgrade System.Interactive.Async to 3.2.0. (#16745 
   )
   - Refactor ServerServiceDefinition and move it to Grpc.Core.Api nuget. (
   #17889 )
   - Allow passing null implementation to generated BindService overload 
   using ServiceBinderBase. (#17837 
   )
   - Move public types needed for server implementation to Grpc.Core.Api. (
   #17778 )

Objective-C
   
   - Disable c-ares on iOS. (#17894 
   )
   - Added support for tvOS. (#17731 
   )
   - Fixing a few thread safety issues in gRPC Objective-C library. (#17578 
   )
   - Rolling out new API for gRPC Objective-C library. (#16190 
   )

Python
   
   - grpc_prefork(): check grpc_is_initialized before creating execctx. (
   #17996 )
   - [gRPC] Enable Python 3 for Bazel to Run Tests. (#17644 
   )
   - Escalate the failure of protoc execution. (#17734 
   )
   - Remove dependency of grpc.framework.foundation.callable_util. (#17543 
   )

Ruby
   
   - Disable service config resolution with c-ares by default, for now. (
   #17998 )
   - Ruby: refactor init/shutdown logic to avoid using atexit; fix windows. 
   (#17997 )
   - Ruby tooling: respect user toolchain overrides. (#17606 
   )

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/feb06837-cfcb-4dd5-9563-267bbee7b6b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Restarting C++ server after shutdown?

[yashkt via grpc.io]

I suggest not shutting down the server too early if there is a possibility 
of using it in the future.

On Wednesday, February 27, 2019 at 4:55:05 AM UTC-8, Antoine Pitrou wrote:
>
>
> Hello, 
>
> If I call the Shutdown() method on a grpc::Server instance, is it 
> possible to start serving again without creating a new Server? 
> It seems that the Wait() method will return immediately if I call it 
> again. 
>
> Use case: I have a signal handler that will shutdown the server. 
> Then, when Wait() returns, I run any Python signal handlers and would 
> like to restart if they didn't raise an exception. 
>
> Regards 
>
> Antoine. 
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/bc43c49b-abb0-4c63-955a-f8ba4a157406%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: c++: Authentication documentation

[yashkt via grpc.io]

There are ways to provide certificates in the guide that you mentioned. Are 
you facing specific problems? https://grpc.io/docs/guides/auth.html

On Monday, February 25, 2019 at 3:16:40 AM UTC-8, maxwel...@gmail.com wrote:
>
> Hi,
>
> I want to setup TLS encryption and token authentication. Under 
> https://grpc.io/docs/guides/auth.html
> I found the following example for using SSL:
>
> auto channel_creds = grpc::SslCredentials(grpc::SslCredentialsOptions());auto 
> channel = grpc::CreateChannel("myservice.example.com", 
> channel_creds);std::unique_ptr stub(Greeter::NewStub(channel));
>
> The above example does not use a certificate. Is the above code working or is 
> the certificate part missing?
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/3b774a2d-bf33-4dee-b0c9-75968e5cfa22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: grpc_insecure_channel_create DNS and connection expectations

[yashkt via grpc.io]

I am speaking from a Core/C++ perspective. Simply creating a channel does 
not lead to connection attempts. It's the first RPC or an explicit connect 
request that triggers it.
To explicitly connect 
- 
https://github.com/grpc/grpc/blob/b0b35b03a7eb775b570c3e186926928641a77690/include/grpcpp/channel.h#L53

On Sunday, February 24, 2019 at 10:04:06 AM UTC-8, Pau Freixes wrote:
>
> Hi, 
>
> Reading the source code of `grpc_insecure_channel_create` [1] seems 
> that this function must trigger in some way the DNS query for the 
> target and also the first connection handshake asynchronously 
>
> Executing one of the Python examples seems that the DNS resolution and 
> the connection are not really done until at least one request is 
> executed [2]. 
>
> Am I missing something? 
>
> If not, is this is the default implementation? So other languages like 
> C++, Java, Node.js are using the same pattern? 
>
> Does the API provide a way of making the connection step explicitly? 
>
> [1] 
> https://github.com/grpc/grpc/blob/8860eb34ab9183589a039a36a6e10a74b440c501/src/core/ext/transport/chttp2/client/insecure/channel_create.cc#L82
>  
> [2] 
> https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client.py#L31
>  
>
> -- 
> --pau 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/8943b3cf-7bf9-46a9-876e-63dc374be0c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] gRPC A6: Retries

['Mark D. Roth' via grpc.io]

Unfortunately, we still can't provide any ETA on this.  We will definitely
get back to this at some point, but we've got other higher priority work
that will be occupying our attention for the next few quarters, so the
soonest we might be able to get back to this would be toward the end of the
year.

FWIW, I am personally committed to getting this done at some point, because
I've already sunk about a year's worth of time into it, and I don't want
that to have been for nothing. :)

On Tue, Feb 26, 2019 at 3:42 PM  wrote:

> Hi, I just wanted to bump this up - any updates on shipping retry support
>  for public use? Thanks.
>
> On Monday, March 13, 2017 at 1:41:39 PM UTC-7, Mark D. Roth wrote:
>>
>> After much discussion with the DNS and security folks, we've decided on a
>> way to address the potential security issue of allowing an attacker to
>> inject a service config with a large number of retries or hedged requests.
>> We will do this by imposing an upper bound on the max number of retries or
>> hedged requests that are configurable via the service config.  That upper
>> bound will be 5 by default, but applications will be able to explicitly
>> override it if needed via a channel argument.
>>
>> This approach not only limits the damage that can be caused by a
>> malicious attacker but also damage that can be caused by a simple typo.
>>
>> Noah, can you please add a section about this to the design doc?  Thanks!
>>
>> On Fri, Feb 10, 2017 at 4:31 PM, ncteisen via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>>> I've created a gRFC describing the design and implementation plan for
>>> gRPC Retries.
>>>
>>> Take a look at the gRPC on Github
>>> .
>>>
>>> --
>>> 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/30e29cbc-439c-46c4-b54f-6e97637a0735%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Mark D. Roth 
>> Software Engineer
>> Google, Inc.
>>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to grpc-io@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/d4134c00-fea6-4e23-a136-5ae730c261e6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Mark D. Roth 
Software Engineer
Google, Inc.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/CAJgPXp5Q%2B-Bm4DsxYNMxKzO9kP4B6_hTAZ%2BQzuPM2dGvCGMzAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Restarting C++ server after shutdown?

[Antoine Pitrou]

Hello,

If I call the Shutdown() method on a grpc::Server instance, is it
possible to start serving again without creating a new Server?
It seems that the Wait() method will return immediately if I call it
again.

Use case: I have a signal handler that will shutdown the server.
Then, when Wait() returns, I run any Python signal handlers and would
like to restart if they didn't raise an exception.

Regards

Antoine.


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/20190227135247.3d4ae6f9%40fsol.
For more options, visit https://groups.google.com/d/optout.