[grpc-io] Re: gRFC L21: GPR API review

['Vijay Pai' via grpc.io]

I view the following as an interesting one. host_port.h provides two 
utility functions for name management: gpr_join_host_port and 
gpr_split_host_port . Both are used in several places inside core. They are 
also used in the core and C++ tests. So those are still fine with 
privatizing.

However, gpr_join_host_port is also used in the objective-C tests. Only in 
the tests, not at all in the implementation. And, as it turns out, those 
tests already dip into src/core in their includes. Thus, I'm going to say 
that host_port.h is privatizable even though objective-C nominally uses it. 
If objective-C later moves to its own repo, it will already have to deal 
with the privatized headers issue for testing anyway.

- Vijay


-- 
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/31edfbcb-d0b8-4f34-acee-8cb2a39df929%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRFC L21: GPR API review

['Vijay Pai' via grpc.io]

Thanks for the feedback! Yes, everything in alloc.h definitely stays since 
those are used in multiple language implementations. Same with time and 
logging -- all the language bindings use them heavily. I think our sync and 
atm also stay since they are certainly used in some of our language 
bindings and presumably in community bindings as well.

On Thursday, January 25, 2018 at 5:11:45 PM UTC-8, Christopher Warrington - 
MSFT wrote:
>
> >  This is a proposal to curate the contents of the include/grpc/support
> >  directory, which is the public surface of the GPR API, as many of the
> >  entries in that API are not actually publicly needed or used. The result
> >  will be a smaller installation and fewer API surface points.
>
> Seems reasonable for my use of gRPC, and the uses I've observed.
>
> Here's a conservative list of the gpr functions that my codebase uses.
>
> * gpr_set_allocation_functions & data structures
> * If this function stays, the getter should probably stay too.
> * gpr_set_log_function & data structures
> * We're not using the gpr_log* functions directly.
> * The gpr_time* functions, as these types are part of the C++ Alarm API
> * We're not using gpr_sleep_until
>
> --
> Christopher Warrington
> Microsoft Corp.
>

-- 
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/6650a340-f3ce-46d4-ad9c-48b1d9d0d988%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRFC L22: Change name of directory `include/grpc++` to `include/grpcxx`

['Srini Polavarapu' via grpc.io]

Is the reason for choosing grpcxx (vs grpc_cpp or grpc_plusplus) is so that 
it is inline with #ifndef GRPCXX_AAA_BBB_H usage in header files? 

On Thursday, January 25, 2018 at 4:44:05 PM UTC-8, Muxi Yan wrote:
>
> grpc.io members,
>
> Please review gRFC proposal L22 
> 
>  which 
> proposes changing the header directory of gRPC C++ library from 
> `include/grpc++` to `include/grpcxx` for compatibility issue. Let me know 
> any question, comment, or concern.
>

-- 
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/d8e56a77-44df-4027-aa05-82ed6c474cf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Is gRPC golang server able to catch the client disconnecting event and do something accordingly?

['yz' via grpc.io]

Thanks Eric. I get your point that the gRPC  client could make multiple 
connections during a session. But if we use a local cache on the server, 
the tricky problem then becomes when the cache item should expire? 


On Friday, January 26, 2018 at 5:57:36 AM UTC+8, Eric Anderson wrote:
>
> On Tue, Jan 23, 2018 at 3:44 AM, 'yz' via grpc.io  > wrote:
>
>> We are implementing authentication on gRPC  Golang server. When a client 
>> connect to the server, it needs to send the token to the server to 
>> authenticate itself, and the server will save the auth info. When the 
>> client disconnect, the server should remove the auth info. But I could not 
>> find a way to be notified when the connection is closed. Does this kind of 
>> transportation supported on gRPC golang server?
>>
>
> I strongly discourage this sort of design. I'd suggest the client provide 
> some authentication token in each RPC (this is inexpensive on-the-wire with 
> HPACK) and optimize using a cache on server-side if necessary.
>
> gRPC is free to recreate connections at any point, or use multiple 
> connections. Also such a service would not work through an L7 load 
> balancer, although I admit many people don't care about that case.
>

-- 
*Grab is hiring. Learn more at **https://grab.careers 
*

By communicating with Grab Inc and/or its subsidiaries, associate companies 
and jointly controlled entities (“Grab Group”), you are deemed to have 
consented to processing of your personal data as set out in the Privacy 
Notice which can be viewed at https://grab.com/privacy/

This email contains confidential information and is only for the intended 
recipient(s). If you are not the intended recipient(s), please do not 
disseminate, distribute or copy this email and notify Grab Group 
immediately if you have received this by mistake and delete this email from 
your system. Email transmission cannot be guaranteed to be secure or 
error-free as any information therein could be intercepted, corrupted, 
lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do 
not accept liability for any errors or omissions in the contents of this 
email arises as a result of email transmission. All intellectual property 
rights in this email and attachments therein shall remain vested in Grab 
Group, unless otherwise provided by law.

-- 
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/12970a7f-3ca2-4180-b87b-d835237e5452%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRFC L21: GPR API review

['Christopher Warrington - MSFT' via grpc.io]

>  This is a proposal to curate the contents of the include/grpc/support
>  directory, which is the public surface of the GPR API, as many of the
>  entries in that API are not actually publicly needed or used. The result
>  will be a smaller installation and fewer API surface points.

Seems reasonable for my use of gRPC, and the uses I've observed.

Here's a conservative list of the gpr functions that my codebase uses.

* gpr_set_allocation_functions & data structures
* If this function stays, the getter should probably stay too.
* gpr_set_log_function & data structures
* We're not using the gpr_log* functions directly.
* The gpr_time* functions, as these types are part of the C++ Alarm API
* We're not using gpr_sleep_until

--
Christopher Warrington
Microsoft Corp.

-- 
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/485b4a53-af51-4d0f-ae26-2b6317a2ef3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRFC L22: Change name of directory `include/grpc++` to `include/grpcxx`

['Muxi Yan' via grpc.io]

grpc.io members,

Please review gRFC proposal L22 

 which 
proposes changing the header directory of gRPC C++ library from 
`include/grpc++` to `include/grpcxx` for compatibility issue. Let me know 
any question, comment, or concern.

-- 
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/24b588ac-8eef-4732-86d5-0a5bdb452813%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRFC L21: GPR API review

['Vijay Pai' via grpc.io]

Hello grpc-io members,

If you don't use gpr_ functions, you can skip this message.

I have posted a new gRFC at https://github.com/grpc/proposal/pull/56/files 
. This is a proposal to curate the contents of the include/grpc/support 
directory, which is the public surface of the GPR API, as many of the 
entries in that API are not actually publicly needed or used. The result 
will be a smaller installation and fewer API surface points.

Thanks,
vjpai

-- 
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/99d80792-1406-428a-ad1f-dc657fc122fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Discarding an cancelled request

['Eric Anderson' via grpc.io]

Just handle the ServerCall directly. Since you don't actually need the
listener, you can give a no-op one. If you need to provide additional error
information, you can provide it in the Metadata.

if (isCancelled) {
  call.close(Status.SOME_STATUS.withDescription("some description"), new
Metadata());
  return new ServerCall.Listener() {};
}

On Thu, Jan 25, 2018 at 10:04 AM,  wrote:

>
> Hi Guys,
>
> I have a grpc service which does some cpu intensive work.
> Before starting the work, I want to ensure that the client hasn't
> cancelled this aforementioned work.
> Rather than checking in every service, I would like to write an
> interceptor which would check and drop the request if it has been cancelled.
>
> This is what I have come up with but I can't figure out how to drop the
> request and signal to the client.
> Any pointers are much appreciated.
>
> Cheers
>
> public final class CancelledRequestInterceptor implements
> ServerInterceptor{
>
> @Override
> public final  Server.Listener interceptCall( ServerCall call
> , Metadata meta, ServerCallHandler next ){
>
> boolean isCancelled = Context.current().isCancelled();
> if( isCancelled ){
>//How do I discard the call and signal to the client that it has
> been discarded
> }else{
>return next.startCall( call, headers );
> }
>
> }
>
>
>
> --
> 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/44bd8313-88c9-4758-a007-28be38cc4c25%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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%2B4M1oPGZnaOqa9tk8k%3DxXKL9GwgdwJpM0R%3D8GsD7oeQSjWE9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] What would be the steps to add Mutual TLS to this HelloWorldTLS example?

['Eric Anderson' via grpc.io]

This discussion was completed in
https://github.com/grpc/grpc-java/issues/4004

-- 
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%2B4M1oMSEixjLiWMKVsH4rrM6W5N4_x7BC8ftKsC-jtgOYT05w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: Is there a way for gRPC server - Go server specifically, to close the the client stream/connection?

['Eric Anderson' via grpc.io]

On Wed, Jan 24, 2018 at 6:49 PM, 'yz' via grpc.io 
wrote:

> Thanks Menghan for the suggestion, but seems it does not fit our scenario
> well.  I noticed that and the cred config is server-wise. What we want to
> achieve is to do the auth in an interceptor, so that it is configurable per
> endpoint on the server.
>

 I responded on one of your other threads
 on some
issues you will encounter with your "TCP-connection is a session" approach.
We can continue the discussion there or here.

-- 
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%2B4M1oMd5kwM7k5Kcw6tveP3wuqZOJSPS%3DV%2BHTb4DDVo1oPrmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Is gRPC golang server able to catch the client disconnecting event and do something accordingly?

['Eric Anderson' via grpc.io]

On Tue, Jan 23, 2018 at 3:44 AM, 'yz' via grpc.io 
wrote:

> We are implementing authentication on gRPC  Golang server. When a client
> connect to the server, it needs to send the token to the server to
> authenticate itself, and the server will save the auth info. When the
> client disconnect, the server should remove the auth info. But I could not
> find a way to be notified when the connection is closed. Does this kind of
> transportation supported on gRPC golang server?
>

I strongly discourage this sort of design. I'd suggest the client provide
some authentication token in each RPC (this is inexpensive on-the-wire with
HPACK) and optimize using a cache on server-side if necessary.

gRPC is free to recreate connections at any point, or use multiple
connections. Also such a service would not work through an L7 load
balancer, although I admit many people don't care about that case.

-- 
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%2B4M1oOOfUUDgNAoYjCXBhAfe6JmydHEFeb6HAF--i2V0o2f7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] (golang) Detecting a dead client

['Eric Anderson' via grpc.io]

On Tue, Jan 23, 2018 at 3:32 AM, 'yz' via grpc.io 
wrote:

> My concern is that if the client connection is closed, no matter
> gracefully or not, the application layer might need to do some cleaning
> according to the event, e.g., to remove authentication information from the
> server. Haven't find a way to do that.
>

Any RPCs that were active at the time will be closed. That is a
notification is good to use. If you're using the TCP connection as a
session, then I'd suggest you strongly consider another option, like some
simplistic caching; there are lots of things that can go wrong with using
knowledge of which TCP connection and RPC is using.

-- 
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%2B4M1oN_sustmM2r7x%3D7KZ11g_dUNJh1dQ4_bTXgVgt2qBJD0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Re: How to fix client-side error: "Endpoint read failed"?

[rkabhi1984]

This part of the error log seems most relevant. It states that the socket 
closed and the connection is no longer valid. I don't understand why this 
is the case as the grpc::ClientReaderWriter object is still active after 
the Read/Write requests are done?

D0124 16:03:06.760391000 140735208460288 connectivity_state.c:185] SET: 
0x7fe460700650 (null): READY --> SHUTDOWN [selected_changed] 
error=0x7fe460624330 
{"created":"@1516838586.76024","description":"Endpoint read 
failed","file":"src/core/ext/transport/chttp2/transport/chttp2_transport.c","file_line":2221,"grpc_status":14,"occurred_during_write":0,"referenced_errors":[{"created":"@1516838586.760238000","description":"Secure
 
read 
failed","file":"src/core/lib/security/transport/secure_endpoint.c","file_line":166,"referenced_errors":[{"created":"@1516838586.760236000","description":"Socket
 
closed","fd":9,"file":"src/core/lib/iomgr/tcp_posix.c","file_line":293,"target_address":"ipv4:10.30.110.86:57400"}]}]}

 

D0124 16:03:06.760486000 140735208460288 connectivity_state.c:185] SET: 
0x7fe460418220 client_channel: READY --> TRANSIENT_FAILURE [lb_changed] 
error=0x7fe460624330 
{"created":"@1516838586.76024","description":"Endpoint read 
failed","file":"src/core/ext/transport/chttp2/transport/chttp2_transport.c","file_line":2221,"grpc_status":14,"occurred_during_write":0,"referenced_errors":[{"created":"@1516838586.760238000","description":"Secure
 
read 
failed","file":"src/core/lib/security/transport/secure_endpoint.c","file_line":166,"referenced_errors":[{"created":"@1516838586.760236000","description":"Socket
 
closed","fd":9,"file":"src/core/lib/iomgr/tcp_posix.c","file_line":293,"target_address":"ipv4:10.30.110.86:57400"}]}]}


Any idea what could be wrong with the code to cause this error?

Thanks,


On Wednesday, January 24, 2018 at 4:15:21 PM UTC-8, rkabh...@gmail.com 
wrote:
>
> I am seeing this error "Endpoint read failed" on the client-side with the 
> below code following this example (
> https://github.com/grpc/grpc/blob/v1.4.5/examples/cpp/route_guide/route_guide_client.cc).
>  
> Using grpc v1.4.5.
>
> The error log is here: 
> https://github.com/abhikeshav/test-code/files/1662114/grpcerror.txt
>
> Any idea how I  can fix this?
>
> grpc::ClientContext context;
> grpc::Status status;
> gnmi::SubscribeResponse response;
>
> std::unique_ptr gnmi::SubscribeResponse>> c = stub_->Subscribe(&context);
> std::shared_ptr gnmi::SubscribeResponse>> cs (move(c));
>
> std::thread writer([cs, payload, operation]() {
>gnmi::SubscribeRequest r;
>gnmi::SubscriptionList* sl = new gnmi::SubscriptionList;
>
>populate_subscribe_request(r, payload, operation, *sl);
>
>cs->Write(r);
>cs->WritesDone();
> });
>
> while (cs->Read(&response))
> {
>   debug_log("Getting subscription data");
> }
>
> writer.join();
> status = cs->Finish();
>
> if (!status.ok())
> {
>   throw(error{status.error_message()});  // Seeing the error here
> }
>
>
>

-- 
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/d313cedc-bdc0-479e-95b9-9390a167e15b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Discarding an cancelled request

[vicvandamne]

Hi Guys,

I have a grpc service which does some cpu intensive work.
Before starting the work, I want to ensure that the client hasn't cancelled 
this aforementioned work.
Rather than checking in every service, I would like to write an interceptor 
which would check and drop the request if it has been cancelled.

This is what I have come up with but I can't figure out how to drop the 
request and signal to the client.
Any pointers are much appreciated.

Cheers

public final class CancelledRequestInterceptor implements ServerInterceptor{

@Override
public final  Server.Listener interceptCall( ServerCall call, 
Metadata meta, ServerCallHandler next ){

boolean isCancelled = Context.current().isCancelled();
if( isCancelled ){
   //How do I discard the call and signal to the client that it has 
been discarded
}else{
   return next.startCall( call, headers );
}

}



-- 
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/44bd8313-88c9-4758-a007-28be38cc4c25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] What would be the steps to add Mutual TLS to this HelloWorldTLS example?

['Spencer Fang' via grpc.io]

This should work in theory but I have not tried it myself:
https://github.com/grpc/grpc-java/issues/3887#issuecomment-358415785

The post discusses the okhttp channel builder targetting android, but the
netty channel builder has a similar setter for the SslContext.

On Thu, Jan 25, 2018 at 7:46 AM,  wrote:

> I created a new HelloWorld with TLS enabled example here:
> https://github.com/grpc/grpc-java/pull/3992
>
> So far I have only configured TLS. Not mutual TLS.
>
> What would be the steps to enable Mutual Auth in this example?
>
> The script added to https://github.com/grpc/grpc-java/pull/3992/files#
> diff-1c0f522a61adc59307209c8e0296db49R39 generates the cert files needed.
>
> But i'm confused where to add those changes to the java code?
>
>
> --
> 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/65f663c9-9fa4-4fbf-afb4-b771b7aa7d20%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Spencer Fang

-- 
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/CAK%3D-x_4YxvePccHG%2Bg6LzzxqYGuQDJTM-z5ZAR2U%2B2SFXQT5wA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] What would be the steps to add Mutual TLS to this HelloWorldTLS example?

[nicholas . dipiazza]

I created a new HelloWorld with TLS enabled example 
here: https://github.com/grpc/grpc-java/pull/3992

So far I have only configured TLS. Not mutual TLS.

What would be the steps to enable Mutual Auth in this example?

The script added 
to 
https://github.com/grpc/grpc-java/pull/3992/files#diff-1c0f522a61adc59307209c8e0296db49R39
 
generates the cert files needed.

But i'm confused where to add those changes to the java code?


-- 
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/65f663c9-9fa4-4fbf-afb4-b771b7aa7d20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Unary Stream from Python server -> C# Client, StatusCode=Unknown, Detail="Stream removed"

[MNS]

I have a unary streaming service from a Python server (1.8.4) to C# client 
(1.8.3). 

When I signal the Python to shutdown (TERM15) the shutdown method in the 
code listing below is called, the intention of which is to terminate the 
rRPCs gracefully, and shut the server down.

This works when I'm running a server on localhost, an RpcException with the 
expected status is raised: `Status(StatusCode=Cancelled, 
Detail="Completed")`

However, when running the server on GKE and terminating the pod I receive: 
`Grpc.Core.RpcException: Status(StatusCode=Unknown, Detail="Stream 
removed")` in the client.  The python server is behind an haproxy ingress 
controller and google-cloud-endpoint proxy, but in my understanding neither 
of these components should affect the connection.

Can anybody think what could be causing the different statuses in the 
RpcException on the client?

Thanks, Mark

def MyHandler(self, request, context):
while not stop_event.isSet():
try:
yield update_q.get(True, 0.1)
except queue.Empty:
continue


context.set_code(grpc.StatusCode.CANCELLED)
context.set_details("Completed")




def shutdown(subscriber_service: StreamsService,
 executor: futures.ThreadPoolExecutor,
 server: grpc.Server, exit_code):


logger.info("Stopping stream handlers")
for stop_event in subscriber_service.stop_events:
stop_event.set()


logger.info("Stopping executor")
executor.shutdown()

logger.info("Stopping server")
ev: threading.Event = server.stop(grace=10)  # allows RPCs to terminate 
gracefully


logger.info("Waiting for server to stop gracefully")
ev.wait()


logger.info("Stopping process with exit code {}".format(exit_code))
sys.exit(exit_code)

-- 
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/939b06d9-1d24-4486-b5fe-c84419bb4f17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: frequently the symbol lookup error is coming

[subhayu . mustafi]

problem with upgrading to v1.8.4 my application always crashes for whihc 
you have sighted to use Poll instead of epoll...

On Thursday, January 25, 2018 at 12:07:58 AM UTC+5:30, Ken Payson wrote:
>
> Can you try upgrading to the latest gRPC (1.8.4 I believe)
>
> There have been significant changes to grpc_exec_ctx.
>
> On Wednesday, January 24, 2018 at 1:14:57 AM UTC-8, subhayu...@gmail.com 
> wrote:
>>
>> ./greeter_server: symbol lookup error: /usr/local/lib/libgrpc++.so.1: 
>> undefined symbol: grpc_exec_ctx_finish
>>
>> After building grpc from source sometimes it disappears
>> V1.7.1 Ubuntu 16.04
>> Aarch64...
>>
>

-- 
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/497e573f-fde8-4825-811b-cdb8c2b1dd3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.