[grpc-io] Re: Trouble with java quickstart for grpc: unable to locate branch 1.6.1

[Jeff Gaer]

I was able to download the tar.gz file of the source and get it to build. 
Not sure why git was not working for me. 

-- 
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/992fcd1c-0fe7-4c8a-8312-24ed506d370a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Trouble with java quickstart for grpc: unable to locate branch 1.6.1

['Eric Gribkoff' via grpc.io]

I'm not sure why you're unable to checkout the tagged release. It is
available on github (https://github.com/grpc/grpc-java/releases/tag/v1.6.1)
and the command (git clone -b ...) works for me. Is it possible you're
getting a cached version of grpc-java?

Thanks,

Eric

On Mon, Sep 18, 2017 at 11:03 AM, Jeff Gaer 
wrote:

> I get the same result with 1.6.1. I had tried the 1.6.2 just as a guess
> along with a variety of other versions. Sorry that I posted the wrong
> command line when I asked the questions. I'm guessing it is a git config
> issue, but I don't have a clue on where to look. There is not of lot of
> content in my gitconfig so I assume I am running with mostly defaults.
>
>
> jgaer@ljgaer1_/data/grpc: git clone -b v1.6.1
> https://github.com/grpc/grpc-java
> Initialized empty Git repository in /data/grpc/grpc-java/.git/
> remote: Counting objects: 52663, done.
> remote: Compressing objects: 100% (30/30), done.
> remote: Total 52663 (delta 7), reused 22 (delta 1), pack-reused 52621
> Receiving objects: 100% (52663/52663), 17.75 MiB | 694 KiB/s, done.
> Resolving deltas: 100% (21774/21774), done.
> warning: Remote branch v1.6.1 not found in upstream origin, using HEAD
> instead
>
> --
> 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/cacb50a1-7287-4627-ab0c-d680ee270b67%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/CALUXJ7h8PXwfx7-HXQ_UwPTg5vNuHiTTmzYX_2w8kRTL8KykNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Trouble with java quickstart for grpc: unable to locate branch 1.6.1

[Jeff Gaer]

I get the same result with 1.6.1. I had tried the 1.6.2 just as a guess 
along with a variety of other versions. Sorry that I posted the wrong 
command line when I asked the questions. I'm guessing it is a git config 
issue, but I don't have a clue on where to look. There is not of lot of 
content in my gitconfig so I assume I am running with mostly defaults. 


jgaer@ljgaer1_/data/grpc: git clone -b v1.6.1  
https://github.com/grpc/grpc-java
Initialized empty Git repository in /data/grpc/grpc-java/.git/
remote: Counting objects: 52663, done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 52663 (delta 7), reused 22 (delta 1), pack-reused 52621
Receiving objects: 100% (52663/52663), 17.75 MiB | 694 KiB/s, done.
Resolving deltas: 100% (21774/21774), done.
warning: Remote branch v1.6.1 not found in upstream origin, using HEAD 
instead

-- 
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/cacb50a1-7287-4627-ab0c-d680ee270b67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Trouble with java quickstart for grpc: unable to locate branch 1.6.1

['Eric Gribkoff' via grpc.io]

It should be v1.6.1, not v1.6.2. See
https://grpc.io/docs/quickstart/java.html, which says to checkout v1.6.1.
Did you find another document saying to use v1.6.2? If so, please let me
know the source for that and I will correct it.

Thanks,

Eric

On Mon, Sep 18, 2017 at 9:26 AM, Jeff Gaer  wrote:

>
> HI,
>
> I am trying to execute the steps in the java quickstart for grpc. When I
> execute git clone -b v1.6.2  https://github.com/grpc/grpc-java I get q
> warning:"warning: Remote branch v1.6.2 not found in upstream origin, using
> HEAD instead" and the checked out version seems to be the latest snapshot.
> I am unable to build the examples  as it can not locate the frpc
> dependancies (i.e Could not find io.grpc:grpc-netty:1.7.0-SNAPSHOT.). I
> googled for the dependancy issue and found that it is a result of trying to
> build a snapshot version, which I guess is what would be on HEAD. How do I
> check out the branch successfully? I am not a big gradle user so pardon the
> dumb question.
>
> --
> 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/4cf63e31-b53b-4c82-ae09-0bb8fa4e84bb%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/CALUXJ7hLBtihDJM%2BhsSkZ%2BLE-x0UrLhG-W-jwA_zGjM%3D9ADWZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRPC streams unexpected disconnections

[Amit Waisel]

I encountered a weird behavior in gRPC.


*The symptom* - an active RPC stream is signaled as cancelled on server 
side (happens from time to time, I couldn't find any correspondence with 
other events in the environment) although the client is active and the 
stream shouldn't be closed.

It happens for streams initialized as response streams in RPC calls from 
both C++ and NodeJS clients. *It happened on gRPC 1.3.6 and still happens 
on gRPC v1.6.0*.

The problem does not reproduced easily - the system is executed under heavy 
load for many hours until this happens.


In my code, I have 2 main types of streams:


   1. Control stream (C++→C#) - the client initiates an RPC call to the 
   server, which keeps the RPC's response stream opened.
   Those streams are used as *control channels* with the *C++ clients* and 
   are kept open to allow server-to-client requests. When they are closed, 
   both client and server clean up all data related to the connection. So, the 
   control stream is critical to the session.
   The server registers on call cancellation notification:
ServerCallContext context; // Received from RPC call as a parameter
// ...
context.CancellationToken.Register(() => System.Threading.ThreadPool.
   QueueUserWorkItem(async obj => { handle_disconnection(...); }));
   
   The total number of opened control streams (AKA number of connected C++ 
   clients) is ~1200. 
   2. Command stream (NodeJS→C#) - There are many many other streams for 
   server-to-client command response communication, which are kept opened in 
   parallel by the server with *NodeJS clients*. The total number of opened 
   streams is 20K-30K. 

The problem is noticeable when the control streams get disconnected.

*Further investigation of the client (C++) and server (C#) logs of control 
stream disconnection, revealed to following*:


   1. For some reason, the server's cancellation token (the one registered 
   above) is signaled - and the server does its cleanup 
   (`handle_disconnection` which also closes many command streams 
   intentionally). *According to the client, the connection should have 
   remained opened.*
   2. After some time, the client realizes the connection was closed 
   unexpectedly and does its cleanup - throwing the error I posted here 
    
   (NodeJS in that case). *The clients disconnects itself only after the 
   server disconnects the connection and control stream.*

Another note - I set the servers' RequestCallTokensPerCompletionQueue value 
for both C++/NodeJS client interfaces, to 32768 (32K) per completion queue.

I have 2 server interfaces (for node clients and C++ clients, which have 
different API), and 4 completion queues (for 8 cores machine). I don't 
really know if the 4 completion queues are global, or per-server.

*Do you think it might cause those streams to be closed under heavy load*?

 

In any case, my suspicious is on the C# server behavior - the 
CancellationToken is signaled for no apparent reason.

I *didn't* rule out network instability yet - although both clients and 
server are located on the same ESX server with 10-gig virtual adapters 
between them, so this is quite a long-shot.

 

Do you have any idea how to solve 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+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/aae6feda-a932-4de5-8519-22c928a36a31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Destroying C++ client stub is not disconnecting the TCP connection to the server

[gustavogb]

Ignore this, it was just a silly bug releasing the stub.   Sorry about it.

El lunes, 18 de septiembre de 2017, 11:41:06 (UTC+2), gust...@gmail.com 
escribió:
>
> Hi,
>
> Due to some special requirements I need to disconnect the client from the 
> server at some point.   I destroy the stub and the channel is supposed to 
> be owned by it but checking with netstat I see the TCP connection to the 
> server is still ESTABLISHED.
>
> This is the code I have. 
>
> auto channel_creds = grpc::SslCredentials(certs_);
>
> auto channel = grpc::CreateChannel(address, channel_creds);
>
> stub_ = proto::api::UsersApi::NewStub(channel);
>
> ... and some time later when I want to disconnect the client I do
>
> stub_.release();
>
>
> Is there anything I'm missing?   How can I totally disconnect the TCP 
> connection to the server?
>
> Thank you very much.
>

-- 
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/2d1ad300-a894-4d5d-a2e2-a33f9000b6e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] [java] Challenge-Response / Digest Auth for GRPC

[William Shallum]

Hi,

Has anyone attempted to do a challenge-response / digest
authentication implementation for GRPC? Our current services use a
token and HTTP Digest authentication to prove ownership of the token's
associated secret without passing it over the wire.

>From what I see in the examples, most of the available authentication
samples is using bearer tokens.

We have locally built a server side interceptor (using the Java API)
that does digest authentication based on metadata in headers. The
client side interceptor also has been created but it does not have
transparent retry capability (e.g. if the nonce expires or on initial
request).

My questions are:

* Is this a good way of doing challenge/response over GRPC?
* Is it possible in the Java API to have an interceptor that can retry
requests transparently?

Your input is greatly appreciated.

Thanks,
William

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

[grpc-io] Destroying C++ client stub is not disconnecting the TCP connection to the server

[gustavogb]

Hi,

Due to some special requirements I need to disconnect the client from the 
server at some point.   I destroy the stub and the channel is supposed to 
be owned by it but checking with netstat I see the TCP connection to the 
server is still ESTABLISHED.

This is the code I have. 

auto channel_creds = grpc::SslCredentials(certs_);

auto channel = grpc::CreateChannel(address, channel_creds);

stub_ = proto::api::UsersApi::NewStub(channel);

... and some time later when I want to disconnect the client I do

stub_.release();


Is there anything I'm missing?   How can I totally disconnect the TCP 
connection to the server?

Thank you very much.

-- 
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/58620fa6-5610-4057-aa5b-55011d7393a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.