Re: [grpc-io] Adding external sockets to grpc event loop

[Aditya]

Thanks for the reply Craig.

Is it possible to do this without adding hacks right now? Can you briefly
describe how would you go about doing this?

On Thu, Feb 16, 2017 at 10:29 PM Craig Tiller  wrote:

> There's not currently, but there's no deep philosophical reason not to. A
> design is needed for how it would function.
>
> On Thu, Feb 16, 2017, 9:22 PM Aditya  wrote:
>
> Is there a way to add external tcp socket fds to grpc event loop?
>
> -Aditya
>
> --
> 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/CAFe7YNxxWhrA%3DzWZdVGuzfyOa%3DZ7dAzJ2ZKbbMd9JTaj8ODD6Q%40mail.gmail.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/CAFe7YNwqnWmdW8%3Du-c3aT78LQShdWEw08B6GOZKNE9C1QL3RLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Adding external sockets to grpc event loop

['Craig Tiller' via grpc.io]

There's not currently, but there's no deep philosophical reason not to. A
design is needed for how it would function.

On Thu, Feb 16, 2017, 9:22 PM Aditya  wrote:

> Is there a way to add external tcp socket fds to grpc event loop?
>
> -Aditya
>
> --
> 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/CAFe7YNxxWhrA%3DzWZdVGuzfyOa%3DZ7dAzJ2ZKbbMd9JTaj8ODD6Q%40mail.gmail.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/CAAvp3oPe5JHwCHCzL2fqoA_kdOXft5QRAq%2BoW06Je3TxK-ZWpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] node.js multiplexing client channels, [is this hack safe?]

['Michael Lumish' via grpc.io]

You should have no problems with this approach, but it also shouldn't be
necessary. gRPC already uses HTTP2 pings to keep channels alive while
they're otherwise idle. If you're still seeing disconnects, there are a
couple of channel options you can set (they go into an object in the third
argument to the Client constructor). The list of them is defined here:
https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L148.
Specifically, modifying "grpc.http2.min_time_between_pings_ms"
and "grpc.http2.max_pings_without_data".

In addition, gRPC automatically reconnects dropped TCP connections, so if
your channel is idle with no ongoing calls, you shouldn't even notice
connection drops.

On Tue, Feb 14, 2017 at 7:36 PM Francesco Lazzarino 
wrote:

> Hi,
>
> The current node.js module doesn't allow one to pass a Channel object to
> build a client, but it does allow one to access a channel via
> grpc.getClientChannel(…) and .$channel on a client object.
>
> In lieu of an exposed interface to pass a connection or channel, I tried
> out the following hack to allow two clients to share the same channel.
>
> function combineChannels(aClient, bClient) {
> var aChan = grpc.getClientChannel(aClient);
> var bChan = grpc.getClientChannel(bClient);
> if (aChan.getTarget() != bChan.getTarget()) {
> throw "different targets: " + " (a) " + aChan.getTarget() + "; (b)
> " + bChan.getTarget();
> }
>
> if (aChan.getConnectivityState() != 0) {
> throw "bad connectivity state (a): " +
> aChan.getConnectivityState();
> }
>
> if (bChan.getConnectivityState() != 0) {
> throw "bad connectivity state (b): " +
> bChan.getConnectivityState();
> }
>
> bChan.close();
> bClient.$channel = aChan;
> }
>
> Observing with nettop (macOS) shows only 1 connection when hack is in use,
> and 1 per client otherwise. It seems to work as expected, but is any danger
> in doing so? Is there a better way to accomplish this in node.js?
>
>
> FWIW my goal is to have a healthcheck client keep the TCP socket alive in
> case a LB or FW wants to close idle-long-running connections.
>
> Thanks in advance,
>
> – Franco
>
> --
> 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/a5f6c9ea-48e4-4d68-a5ab-322c55c15f21%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/CAPK2-4dkczkAHZJv_-7yg_EHf1DeHuuR0FAQ_hj8P%2Bc4rRpvfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: GRFC L4 Add JRuby Support

[Nicolas Noble]

Personally, I wouldn't see Kailash's last comment as a minor comment as he
says; this is a major problem with that gRFC: deciding between JNI or Java,
and outlining the details of how to actually implement an API that would be
compatible with the current one is a design decision that needs to be
investigated, and fully described by the gRFC.

On Thu, Feb 16, 2017 at 3:17 PM, kailashs via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi Jason,
>
> Thanks for sending this proposal, I took a look and had some comments:
>
> 1) As per the proposal, I think that the recommended approach is indeed go
> down the path of a java library wrapper. JNI wrapping is another
> possibility, but we should first investigate whether the Java wrapper is
> not possible before considering it.
> 2) IMO the jruby implementation can live in a separate repository and I
> would recommend this to start with. In the future, when the wrapped
> implementation is stable and passes interop tests we can consider merging
> it into the main repo. I would recommend starting this work outside of the
> main gRPC repo. The grpc-ecosystem org 
> is a good candidate. This will allow for maximum flexibility.
> 3) It would be useful to define some shallow tests that cover the API.
> Such tests should be added to the existing Ruby implementation first, and
> can then be used to ensure that the jruby implementation conforms. See
> https://github.com/grpc/grpc/blob/master/src/python/grpcio_
> tests/tests/unit/_api_test.py for a starting point. I must reiterate that
> this type of testing is very shallow and is not sufficient in itself, but a
> good addition to the interop tests.
> 4) For any gRPC implementation, we need to ensure that the interop tests
> pass. See https://github.com/grpc/grpc-java/tree/master/interop-testing,
> https://github.com/grpc/grpc/tree/master/src/ruby/pb/test and
> https://github.com/grpc/grpc/blob/master/doc/interop-test-descriptions.md.
> The jruby implementation needs to pass these in order to be considered
> conforming. We recommend re-using the ruby interop test suite with the
> jruby wrapper to the extent possible, independent of the java suite (of
> course, these can be leveraged as needed). The nice thing is that if the
> APIs fully conform, the ruby interop tests should just pass.
> 5) Given the difference between Java and C stacks, there may be API
> incompatibilities that might not be surmountable, especially in situations
> where the C core implementation specifics is directly exposed upward. Such
> situations need to be quantified and further down the line, we can decide
> how to tackle them and weigh the cost of doing just that vs a full JNI
> implementation.
>
> Some minor comments on the proposal doc itself:
>
> 1) Please add details on implementation ownership, so that it can be
> discussed. Its unclear if this is something that the proposer is signing up
> to implement, is that the plan?
>
> 2) Could you please update the proposal to cover the implementation
> approach in more detail based on some of these points. Ie: Location of the
> prototype repo, some discussion on the API surfaces that need to be
> conformed to and potential areas you have identified as problematic. This
> can go hand in hand with a prototype of the java wrapped approach so that
> we can tackle issues as they happen.
>
>
> Thanks!
> Kailash
>
>
>
>
>
>
> On Thursday, February 16, 2017 at 10:36:25 AM UTC-8, Mike Moore wrote:
>>
>> On Thu, Feb 16, 2017 at 9:08 AM, Jason Lunn  wrote:
>>
>>> It has probably been a decade since I had a reason to try to use JNI.
>>> Does anyone have any experience building Gems using that approach? Would it
>>> be the case that there would be one JAR per supported platform (
>>> x64-mingw32, x86_64-linux, universal-darwin, x86-mingw32), or would it
>>> be a fat jar that include multiple JNI wrappers?
>>>
>>> I am not clear on what capabilities of the existing gem are needed to
>>> satisfy the dependency of the Google Cloud gem (which is my personal
>>> motivation to see this move forward). Maybe Mike Moore knows better if the
>>> client side would be enough?
>>>
>>
>> The Google Cloud gems are clients only, and so supporting the client-half
>> of GRPC would be sufficient for our use of GRPC.
>>
>>
>>> I think I prefer to see the JRuby support sit alongside the existing
>>> Ruby code in the same repository, and tested in a consistent way. This will
>>> help avoid breaking behavior from slipping into the C implementation that
>>> isn't observed until someone thinks to update the other repo. It should
>>> also make it less likely that a gem update is released for the C derived
>>> platforms without a corresponding update for the JRuby variant.
>>>
>>> On Wednesday, February 15, 2017 at 1:30:59 PM UTC-5, apo...@google.com
>>> wrote:

 As has been noted before, I think this would be possible by doing a
 pure implementation, wrapping the java client, 

[grpc-io] Re: tcp_server_posix.c:395] Failed accept4: Invalid argument

['David Garcia Quintas' via grpc.io]

Hi Okke,

Not really answering what the cause of that error was, but, would it be 
possible for you to upgrade to a more recent version? Lots of bug fixes 
have happened around that part of the codebase.

On Wednesday, 30 November 2016 00:37:00 UTC-8, Okke Hendriks wrote:
>
>
> Hello,
>
> I am using gRPC C++ 1.0.0 and running multiple nightly tests.
> One of these tests is qualifying if on/multiple client can connect to a 
> server.
> Sporadically i am getting the following error in the output of my tests:
>
> tcp_server_posix.c:395] Failed accept4: Invalid argument
>
> When this happens, client are also unable to connect:
>
> connection.test.h:71: Failure
> Value of: mClient->Connected()
>   Actual: false
> Expected: true
> connection.test.h:72: Failure
> Value of: mClient->WaitForConnected(std::chrono::milliseconds(
> TEST_CONNECTION_WAIT))
>   Actual: false
> Expected: true
>
> So it seems that the server never starts running or at least does not 
> accept connections.
>
> When checking linux manual I am seeing the following:
> *EINVAL* (*accept4*()) invalid value in *flags*.
>
> The server and client(s) are both created in the same gtest process, 
> running on a port on localhost.
>
> I am not yet able to reproduce this consistently, but I am asking anyway 
> in the hope this is known to someone here, or if somebody has an idea to 
> reproduce this more consistently.
>

-- 
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/e837a751-9eea-474f-9baa-f007666906d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: GRFC L4 Add JRuby Support

[Mike Moore]

On Thu, Feb 16, 2017 at 9:08 AM, Jason Lunn  wrote:

> It has probably been a decade since I had a reason to try to use JNI. Does
> anyone have any experience building Gems using that approach? Would it be
> the case that there would be one JAR per supported platform (x64-mingw32,
> x86_64-linux, universal-darwin, x86-mingw32), or would it be a fat jar
> that include multiple JNI wrappers?
>
> I am not clear on what capabilities of the existing gem are needed to
> satisfy the dependency of the Google Cloud gem (which is my personal
> motivation to see this move forward). Maybe Mike Moore knows better if the
> client side would be enough?
>

The Google Cloud gems are clients only, and so supporting the client-half
of GRPC would be sufficient for our use of GRPC.


> I think I prefer to see the JRuby support sit alongside the existing Ruby
> code in the same repository, and tested in a consistent way. This will help
> avoid breaking behavior from slipping into the C implementation that isn't
> observed until someone thinks to update the other repo. It should also make
> it less likely that a gem update is released for the C derived platforms
> without a corresponding update for the JRuby variant.
>
> On Wednesday, February 15, 2017 at 1:30:59 PM UTC-5, apo...@google.com
> wrote:
>>
>> 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 client-side library
>> is needed, then perhaps the jruby-platform target could only need to
>> emulate the client-half of the c-wrapping grpc-ruby (would probably
>> simplify things).
>>
>> As for where the project could live though, one option is it could go
>> into the same grpc repo as current grpc-ruby. Another is it could be done
>> entirely as a third party project in its own repo, for which we could give
>> some guidance.
>>
>> On Wednesday, February 15, 2017 at 8:59:31 AM UTC-8, Jason Lunn wrote:
>>>
>>> There is a GRFC  to add
>>> support for the JRuby  interpreter, which runs on
>>> the JVM.
>>>
>>> Please provide all feedback on this thread.
>>>
>>

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

[grpc-io] Re: GRFC L4 Add JRuby Support

[Jason Lunn]

It has probably been a decade since I had a reason to try to use JNI. Does 
anyone have any experience building Gems using that approach? Would it be 
the case that there would be one JAR per supported platform (x64-mingw32, 
x86_64-linux, universal-darwin, x86-mingw32), or would it be a fat jar that 
include multiple JNI wrappers?

I am not clear on what capabilities of the existing gem are needed to 
satisfy the dependency of the Google Cloud gem (which is my personal 
motivation to see this move forward). Maybe Mike Moore knows better if the 
client side would be enough?

I think I prefer to see the JRuby support sit alongside the existing Ruby 
code in the same repository, and tested in a consistent way. This will help 
avoid breaking behavior from slipping into the C implementation that isn't 
observed until someone thinks to update the other repo. It should also make 
it less likely that a gem update is released for the C derived platforms 
without a corresponding update for the JRuby variant.

On Wednesday, February 15, 2017 at 1:30:59 PM UTC-5, apo...@google.com 
wrote:
>
> 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 client-side library is 
> needed, then perhaps the jruby-platform target could only need to emulate 
> the client-half of the c-wrapping grpc-ruby (would probably simplify 
> things).
>
> As for where the project could live though, one option is it could go into 
> the same grpc repo as current grpc-ruby. Another is it could be done 
> entirely as a third party project in its own repo, for which we could give 
> some guidance.
>
> On Wednesday, February 15, 2017 at 8:59:31 AM UTC-8, Jason Lunn wrote:
>>
>> There is a GRFC  to add 
>> support for the JRuby  interpreter, which runs on the 
>> JVM.
>>
>> Please provide all feedback on this thread.
>>
>

-- 
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/7aac229b-2b25-440a-833f-df9eaf622e4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] grpc-go: client for service reflection

[Josh Humphries]

I noticed there is a server-side implementation

in Go for service reflection
.
But a client is notably absent. Using a generated stub is inconvenient for
numerous reasons, not least among them being that the generated API of raw
descriptor protos is rather unwieldy.

I've written such a client

and was wondering if it would be considered a useful addition to the core
grpc-go repo. It provides a richer descriptor type, similar to what is done
in Java and C++ protobuf implementations, to make the returned schema
easier to use.


(I've also asked the protobuf mailing list if the descriptors would be a
welcome contribution to the Go protobuf library. Although I don't see my
message in Google Groups -- anyone know if that group is moderated?)


*Josh Humphries*
jh...@bluegosling.com

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

Re: [grpc-io] How can I use nginx 1.9.5 as reverse proxy with gRPC?

['Stanley Cheung' via grpc.io]

The PHP use case is as follows:

   - Your frontend client (e.g. browser, mobile) is hitting your Nginx
   reverse proxy
   - Perhaps that's a PHP script that the user is requesting. Nginx is
   launching a fastcgi process to run your PHP script.
   - This PHP script can be used as a gRPC client itself, to communicate
   further with a gRPC backend server that could have been implemented in any
   language.

Hope that helps.

On Thu, Feb 16, 2017 at 12:30 AM,  wrote:

> Thanks guys, It's very pleasure to join this group.
>
>
> I want to write my backend code with Java, and my reverse proxy engine is
> NGINX 1.11.9(which has been supported HTTP/2), I saw the gRPC PHP has been
> adapted with NGINX with the doc:  https://github.com/grpc/grpc/
> tree/master/src/php#use-the-grpc-php-extension-with-nginxphp-fpm
>
>
> But no doc for any other repo, such as gRPC Java even some relates tips.
>
>
> So I was searching for it, but further searching, more confuse, because
> gRPC PHP is worked with NGINX, in theory, gRPC can work too, isn't it? But
> I also saw there is an issue
>  
> said
> it is in the process of submitting a 3rd party module
> in nginx for grpc support without update, and there is a ticket
>  on NGINX means we can't write
> HTTP/2 NGINX proxy module for gRPC, and also saw nginx does not support
> the full HTTP/2 specs, gRPC does not work through it
> 
>
>
> 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/8d6ecd6e-1f55-43c0-85da-bdee64237d02%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/CAEteGX1gHtO5%2BB%3DR-EKG9fjYSnim1%2B%3Dsws%3DQgsN9CSF9eGeB%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] How can I use nginx 1.9.5 as reverse proxy with gRPC?

[igzhenjie]

Thanks guys, It's very pleasure to join this group.


I want to write my backend code with Java, and my reverse proxy engine is 
NGINX 1.11.9(which has been supported HTTP/2), I saw the gRPC PHP has been 
adapted with NGINX with the doc:  
https://github.com/grpc/grpc/tree/master/src/php#use-the-grpc-php-extension-with-nginxphp-fpm


But no doc for any other repo, such as gRPC Java even some relates tips.


So I was searching for it, but further searching, more confuse, because 
gRPC PHP is worked with NGINX, in theory, gRPC can work too, isn't it? But 
I also saw there is an issue 
 said 
it is in the process of submitting a 3rd party module 
in nginx for grpc support without update, and there is a ticket 
 on NGINX means we can't write 
HTTP/2 NGINX proxy module for gRPC, and also saw nginx does not support the 
full HTTP/2 specs, gRPC does not work through it 



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/8d6ecd6e-1f55-43c0-85da-bdee64237d02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.