Re: [grpc-io] Kill server task if client disconnects? (python)

['Lidi Zheng' via grpc.io]

That's kind of unfortunate, the server-side fork support seems not
happening soon. Here is the issue #16001
 to track the progress of
server-side fork support.
Please left a comment in that PR, if this feature is critical for you.
Hopefully, its prioritization can be increased.

On Thu, Feb 28, 2019 at 5:49 PM Josh Liburdi 
wrote:

> Agreed that my problem goes beyond the scope of gRPC, I was mostly curious
> if you had any creative ideas for handling this (and thanks for the ones
> you shared). The only thing, I think, gRPC could do to help in these cases
> is allow RPCs to be handled by processes and not threads.
>
> On Thu, Feb 28, 2019 at 5:30 PM lidiz via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> You question is beyond gRPC framework, and one cannot interrupt thread
>> has been a headache for Python (and programming languages with
>> multi-threading) for a long time.
>>
>> Alternatively, you could:
>>
>> 1) Have the server thread instead of sleep for a complete 5 minute, you
>> can break it down to like 1 second and check for termination flag. The
>> termination flag can be flipped by other threads.
>> 2) If the job you run can be ran with "subprocess", then it will be
>> easier to control its life cycle.
>> 3) Wrap your job with Python one of "Future" implementation.
>> 4̶)̶ ̶I̶n̶v̶o̶k̶e̶ ̶C̶P̶y̶t̶h̶o̶n̶ ̶C̶ ̶A̶P̶I̶
>> ̶P̶y̶T̶h̶r̶e̶a̶d̶S̶t̶a̶t̶e̶_̶S̶e̶t̶A̶s̶y̶n̶c̶E̶x̶c̶
>> .̶
>>
>>
>>
>> On Thursday, February 28, 2019 at 5:14:18 PM UTC-8, Josh Liburdi wrote:
>>>
>>> That is a good example of using the callback! Where I get stuck is the
>>> first example you mentioned, cancelling the running job. A simulation of my
>>> problem would be to have the server perform a very long task (e.g. 5 minute
>>> sleep call); in those cases, I would need the callback to interrupt/cancel
>>> that sleep call. Usually I would handle this with signals and setting an
>>> explicit timer in the server process, but (from what I’ve seen and read)
>>> signals cannot be used in threads.
>>>
>>> On Thu, Feb 28, 2019 at 4:48 PM lidiz via grpc.io <
>>> grp...@googlegroups.com> wrote:
>>>
>> I wrote an example about the "add_callback" API last December after
 reading this thread: https://github.com/grpc/grpc/pull/17551. But I
 haven't really push to merge that pull request.
 You can add your special logic in the server-side callback, like cancel
 the running job, log metrics, and other stuff.
 Please take a look at the example, and let me know if it failed to
 solve your question.


 On Thursday, February 28, 2019 at 4:32:07 PM UTC-8,
 liburdi...@gmail.com wrote:
>
> Out of curiosity, can anyone show an example of how add_callback can
> be used to interrupt the server-side process? I have the same problem as
> the OP for my application -- server-side can run for a very long time and
> if the client times out, then I need the server to cancel immediately. 
> I've
> tried a variety of techniques, but I cannot get the callback function to
> stop the server-side call.
>
> On Tuesday, December 18, 2018 at 12:51:23 PM UTC-8, vbp...@gmail.com
> wrote:
>>
>> Ah; thanks--we're having to use subprocess.Popen in a few cases
>> anyway.  I'll try that and see what we can do.  Thanks for the note on
>> "grpc within grpc"; that may simplify some things too.
>>
>> On Tuesday, December 18, 2018 at 1:07:00 PM UTC-6, Eric Gribkoff
>> wrote:
>>>
>>>
>>>
>>> On Tue, Dec 18, 2018 at 10:45 AM  wrote:
>>>
 Thanks, Eric.  That makes some degree of sense, although there are
 a few cases we still won't be able to deal with, I suspect (and we may 
 have
 trouble later anyway... in some cases our server program has to shell 
 out
 to run a separate program, and if that runs into the fork trouble and 
 can't
 be supported by GRPC we may be stuck with a very clanky REST
 implementation).


>>> Sorry, I should have been more precise in my earlier response: you
>>> are fine to use fork+exec (e.g., subprocess.Popen) to run a separate
>>> program in a new shell. (Caveat: we had a bug
>>>  that may cause problems
>>> even with fork+exec when using Python3. The fix is now merged and will 
>>> be
>>> in the next release; our nightly builds will also include the fix 
>>> ~tomorrow
>>> if you are hitting this issue). The issues on the server-side with fork
>>> arise when using libraries that fork and, rather than exec'ing a new
>>> program, continue to run the original program in the child process, 
>>> e.g.,
>>> Python's multiprocessing module.
>>>
>>>
>>>
 Hmm, quite a pickle.  I can see I'll be playing with a bunch of t

Re: [grpc-io] Kill server task if client disconnects? (python)

[Josh Liburdi]

Agreed that my problem goes beyond the scope of gRPC, I was mostly curious
if you had any creative ideas for handling this (and thanks for the ones
you shared). The only thing, I think, gRPC could do to help in these cases
is allow RPCs to be handled by processes and not threads.

On Thu, Feb 28, 2019 at 5:30 PM lidiz via grpc.io 
wrote:

> You question is beyond gRPC framework, and one cannot interrupt thread has
> been a headache for Python (and programming languages with multi-threading)
> for a long time.
>
> Alternatively, you could:
>
> 1) Have the server thread instead of sleep for a complete 5 minute, you
> can break it down to like 1 second and check for termination flag. The
> termination flag can be flipped by other threads.
> 2) If the job you run can be ran with "subprocess", then it will be easier
> to control its life cycle.
> 3) Wrap your job with Python one of "Future" implementation.
> 4̶)̶ ̶I̶n̶v̶o̶k̶e̶ ̶C̶P̶y̶t̶h̶o̶n̶ ̶C̶ ̶A̶P̶I̶
> ̶P̶y̶T̶h̶r̶e̶a̶d̶S̶t̶a̶t̶e̶_̶S̶e̶t̶A̶s̶y̶n̶c̶E̶x̶c̶
> .̶
>
>
>
> On Thursday, February 28, 2019 at 5:14:18 PM UTC-8, Josh Liburdi wrote:
>>
>> That is a good example of using the callback! Where I get stuck is the
>> first example you mentioned, cancelling the running job. A simulation of my
>> problem would be to have the server perform a very long task (e.g. 5 minute
>> sleep call); in those cases, I would need the callback to interrupt/cancel
>> that sleep call. Usually I would handle this with signals and setting an
>> explicit timer in the server process, but (from what I’ve seen and read)
>> signals cannot be used in threads.
>>
>> On Thu, Feb 28, 2019 at 4:48 PM lidiz via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
> I wrote an example about the "add_callback" API last December after
>>> reading this thread: https://github.com/grpc/grpc/pull/17551. But I
>>> haven't really push to merge that pull request.
>>> You can add your special logic in the server-side callback, like cancel
>>> the running job, log metrics, and other stuff.
>>> Please take a look at the example, and let me know if it failed to solve
>>> your question.
>>>
>>>
>>> On Thursday, February 28, 2019 at 4:32:07 PM UTC-8, liburdi...@gmail.com
>>> wrote:

 Out of curiosity, can anyone show an example of how add_callback can be
 used to interrupt the server-side process? I have the same problem as the
 OP for my application -- server-side can run for a very long time and if
 the client times out, then I need the server to cancel immediately. I've
 tried a variety of techniques, but I cannot get the callback function to
 stop the server-side call.

 On Tuesday, December 18, 2018 at 12:51:23 PM UTC-8, vbp...@gmail.com
 wrote:
>
> Ah; thanks--we're having to use subprocess.Popen in a few cases
> anyway.  I'll try that and see what we can do.  Thanks for the note on
> "grpc within grpc"; that may simplify some things too.
>
> On Tuesday, December 18, 2018 at 1:07:00 PM UTC-6, Eric Gribkoff wrote:
>>
>>
>>
>> On Tue, Dec 18, 2018 at 10:45 AM  wrote:
>>
>>> Thanks, Eric.  That makes some degree of sense, although there are a
>>> few cases we still won't be able to deal with, I suspect (and we may 
>>> have
>>> trouble later anyway... in some cases our server program has to shell 
>>> out
>>> to run a separate program, and if that runs into the fork trouble and 
>>> can't
>>> be supported by GRPC we may be stuck with a very clanky REST
>>> implementation).
>>>
>>>
>> Sorry, I should have been more precise in my earlier response: you
>> are fine to use fork+exec (e.g., subprocess.Popen) to run a separate
>> program in a new shell. (Caveat: we had a bug
>>  that may cause problems
>> even with fork+exec when using Python3. The fix is now merged and will be
>> in the next release; our nightly builds will also include the fix 
>> ~tomorrow
>> if you are hitting this issue). The issues on the server-side with fork
>> arise when using libraries that fork and, rather than exec'ing a new
>> program, continue to run the original program in the child process, e.g.,
>> Python's multiprocessing module.
>>
>>
>>
>>> Hmm, quite a pickle.  I can see I'll be playing with a bunch of toy
>>> problems for a bit before even considering doing a migration to GRPC.  
>>> Most
>>> disagreeable, but we'll see what we get.
>>>
>>> Can grpc client stubs be used from within grpc servicers?
>>> (imagining fracturing this whole thing into microservices even if that
>>> doesn't solve this particular problem).
>>>
>>
>> Absolutely, and that's an intended/common usage.
>>
>> Thanks,
>>
>> Eric
>>
>>
>>>
>>> On Tuesday, December 18, 2018 at 12:32:15 PM UTC-6,

Re: [grpc-io] Kill server task if client disconnects? (python)

[lidiz via grpc.io]

You question is beyond gRPC framework, and one cannot interrupt thread has 
been a headache for Python (and programming languages with multi-threading) 
for a long time.

Alternatively, you could:

1) Have the server thread instead of sleep for a complete 5 minute, you can 
break it down to like 1 second and check for termination flag. The 
termination flag can be flipped by other threads.
2) If the job you run can be ran with "subprocess", then it will be easier 
to control its life cycle.
3) Wrap your job with Python one of "Future" implementation.
4̶)̶ ̶I̶n̶v̶o̶k̶e̶ ̶C̶P̶y̶t̶h̶o̶n̶ ̶C̶ ̶A̶P̶I̶ 
̶P̶y̶T̶h̶r̶e̶a̶d̶S̶t̶a̶t̶e̶_̶S̶e̶t̶A̶s̶y̶n̶c̶E̶x̶c̶ 
.̶



On Thursday, February 28, 2019 at 5:14:18 PM UTC-8, Josh Liburdi wrote:
>
> That is a good example of using the callback! Where I get stuck is the 
> first example you mentioned, cancelling the running job. A simulation of my 
> problem would be to have the server perform a very long task (e.g. 5 minute 
> sleep call); in those cases, I would need the callback to interrupt/cancel 
> that sleep call. Usually I would handle this with signals and setting an 
> explicit timer in the server process, but (from what I’ve seen and read) 
> signals cannot be used in threads.
>
> On Thu, Feb 28, 2019 at 4:48 PM lidiz via grpc.io  > wrote:
>
>> I wrote an example about the "add_callback" API last December after 
>> reading this thread: https://github.com/grpc/grpc/pull/17551. But I 
>> haven't really push to merge that pull request. 
>> You can add your special logic in the server-side callback, like cancel 
>> the running job, log metrics, and other stuff.
>> Please take a look at the example, and let me know if it failed to solve 
>> your question.
>>
>>
>> On Thursday, February 28, 2019 at 4:32:07 PM UTC-8, liburdi...@gmail.com 
>> wrote:
>>>
>>> Out of curiosity, can anyone show an example of how add_callback can be 
>>> used to interrupt the server-side process? I have the same problem as the 
>>> OP for my application -- server-side can run for a very long time and if 
>>> the client times out, then I need the server to cancel immediately. I've 
>>> tried a variety of techniques, but I cannot get the callback function to 
>>> stop the server-side call.
>>>
>>> On Tuesday, December 18, 2018 at 12:51:23 PM UTC-8, vbp...@gmail.com 
>>> wrote:

 Ah; thanks--we're having to use subprocess.Popen in a few cases 
 anyway.  I'll try that and see what we can do.  Thanks for the note on 
 "grpc within grpc"; that may simplify some things too.

 On Tuesday, December 18, 2018 at 1:07:00 PM UTC-6, Eric Gribkoff wrote:
>
>
>
> On Tue, Dec 18, 2018 at 10:45 AM  wrote:
>
>> Thanks, Eric.  That makes some degree of sense, although there are a 
>> few cases we still won't be able to deal with, I suspect (and we may 
>> have 
>> trouble later anyway... in some cases our server program has to shell 
>> out 
>> to run a separate program, and if that runs into the fork trouble and 
>> can't 
>> be supported by GRPC we may be stuck with a very clanky REST 
>> implementation).
>>
>>
> Sorry, I should have been more precise in my earlier response: you are 
> fine to use fork+exec (e.g., subprocess.Popen) to run a separate program 
> in 
> a new shell. (Caveat: we had a bug 
>  that may cause problems 
> even with fork+exec when using Python3. The fix is now merged and will be 
> in the next release; our nightly builds will also include the fix 
> ~tomorrow 
> if you are hitting this issue). The issues on the server-side with fork 
> arise when using libraries that fork and, rather than exec'ing a new 
> program, continue to run the original program in the child process, e.g., 
> Python's multiprocessing module.
>
>  
>
>> Hmm, quite a pickle.  I can see I'll be playing with a bunch of toy 
>> problems for a bit before even considering doing a migration to GRPC.  
>> Most 
>> disagreeable, but we'll see what we get.
>>
>> Can grpc client stubs be used from within grpc servicers?  (imagining 
>> fracturing this whole thing into microservices even if that doesn't 
>> solve 
>> this particular problem).
>>
>
> Absolutely, and that's an intended/common usage.
>
> Thanks,
>
> Eric
>  
>
>>
>> On Tuesday, December 18, 2018 at 12:32:15 PM UTC-6, Eric Gribkoff 
>> wrote:
>>>
>>>
>>>
>>> On Tue, Dec 18, 2018 at 10:17 AM  wrote:
>>>
 Hmm; I'm having some luck looking at the context, which quite 
 happily changes from is_active() to not is_active() the instant I kill 
 the 
 waiting client.  So I thought I'd proceed with something like

 while not my_future.done():
   if not context.

Re: [grpc-io] Kill server task if client disconnects? (python)

[Josh Liburdi]

That is a good example of using the callback! Where I get stuck is the
first example you mentioned, cancelling the running job. A simulation of my
problem would be to have the server perform a very long task (e.g. 5 minute
sleep call); in those cases, I would need the callback to interrupt/cancel
that sleep call. Usually I would handle this with signals and setting an
explicit timer in the server process, but (from what I’ve seen and read)
signals cannot be used in threads.

On Thu, Feb 28, 2019 at 4:48 PM lidiz via grpc.io 
wrote:

> I wrote an example about the "add_callback" API last December after
> reading this thread: https://github.com/grpc/grpc/pull/17551. But I
> haven't really push to merge that pull request.
> You can add your special logic in the server-side callback, like cancel
> the running job, log metrics, and other stuff.
> Please take a look at the example, and let me know if it failed to solve
> your question.
>
>
> On Thursday, February 28, 2019 at 4:32:07 PM UTC-8, liburdi...@gmail.com
> wrote:
>>
>> Out of curiosity, can anyone show an example of how add_callback can be
>> used to interrupt the server-side process? I have the same problem as the
>> OP for my application -- server-side can run for a very long time and if
>> the client times out, then I need the server to cancel immediately. I've
>> tried a variety of techniques, but I cannot get the callback function to
>> stop the server-side call.
>>
>> On Tuesday, December 18, 2018 at 12:51:23 PM UTC-8, vbp...@gmail.com
>> wrote:
>>>
>>> Ah; thanks--we're having to use subprocess.Popen in a few cases anyway.
>>> I'll try that and see what we can do.  Thanks for the note on "grpc within
>>> grpc"; that may simplify some things too.
>>>
>>> On Tuesday, December 18, 2018 at 1:07:00 PM UTC-6, Eric Gribkoff wrote:



 On Tue, Dec 18, 2018 at 10:45 AM  wrote:

> Thanks, Eric.  That makes some degree of sense, although there are a
> few cases we still won't be able to deal with, I suspect (and we may have
> trouble later anyway... in some cases our server program has to shell out
> to run a separate program, and if that runs into the fork trouble and 
> can't
> be supported by GRPC we may be stuck with a very clanky REST
> implementation).
>
>
 Sorry, I should have been more precise in my earlier response: you are
 fine to use fork+exec (e.g., subprocess.Popen) to run a separate program in
 a new shell. (Caveat: we had a bug
  that may cause problems
 even with fork+exec when using Python3. The fix is now merged and will be
 in the next release; our nightly builds will also include the fix ~tomorrow
 if you are hitting this issue). The issues on the server-side with fork
 arise when using libraries that fork and, rather than exec'ing a new
 program, continue to run the original program in the child process, e.g.,
 Python's multiprocessing module.



> Hmm, quite a pickle.  I can see I'll be playing with a bunch of toy
> problems for a bit before even considering doing a migration to GRPC.  
> Most
> disagreeable, but we'll see what we get.
>
> Can grpc client stubs be used from within grpc servicers?  (imagining
> fracturing this whole thing into microservices even if that doesn't solve
> this particular problem).
>

 Absolutely, and that's an intended/common usage.

 Thanks,

 Eric


>
> On Tuesday, December 18, 2018 at 12:32:15 PM UTC-6, Eric Gribkoff
> wrote:
>>
>>
>>
>> On Tue, Dec 18, 2018 at 10:17 AM  wrote:
>>
>>> Hmm; I'm having some luck looking at the context, which quite
>>> happily changes from is_active() to not is_active() the instant I kill 
>>> the
>>> waiting client.  So I thought I'd proceed with something like
>>>
>>> while not my_future.done():
>>>   if not context.is_active():
>>> my_future.cancel()
>>>
>>>
>> Consider using add_callback
>>  on
>> the RpcContext instead, so you don't have to poll.
>>
>>
>>> Terminating the worker thread/process is actually vexing me though!
>>> I tried having a ThreadPoolExecutor to give me a future for the worker
>>> task, but you can't really cancel a future from a thread, it turns out 
>>> (you
>>> can only cancel it if it hasn't started running; once it's started, it
>>> still goes to completion).  So I've tried having a separate
>>> ProcessPoolExecutor (maybe processes can be killed?) but that's not
>>> actually going so well either, as attempts to use that to generate 
>>> futures
>>> results in some odd "Failed accept4: Invalid Argument" errors which I 
>>> can't
>>> quite work through.
>>>
>>>
>> ProcessPoolExecutor will fork subprocesses, an

[grpc-io] L48: Node types package

['Michael Lumish' via grpc.io]

Discussion thread for proposal: https://github.com/grpc/proposal/pull/126

-- 
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-4cuXmYhCXhEr6c0TWob%3D3-d_XFDttrxww34uu5%3D6V%2B-vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Kill server task if client disconnects? (python)

[lidiz via grpc.io]

I wrote an example about the "add_callback" API last December after reading 
this thread: https://github.com/grpc/grpc/pull/17551. But I haven't really 
push to merge that pull request. 
You can add your special logic in the server-side callback, like cancel the 
running job, log metrics, and other stuff.
Please take a look at the example, and let me know if it failed to solve 
your question.

On Thursday, February 28, 2019 at 4:32:07 PM UTC-8, liburdi...@gmail.com 
wrote:
>
> Out of curiosity, can anyone show an example of how add_callback can be 
> used to interrupt the server-side process? I have the same problem as the 
> OP for my application -- server-side can run for a very long time and if 
> the client times out, then I need the server to cancel immediately. I've 
> tried a variety of techniques, but I cannot get the callback function to 
> stop the server-side call.
>
> On Tuesday, December 18, 2018 at 12:51:23 PM UTC-8, vbp...@gmail.com 
> wrote:
>>
>> Ah; thanks--we're having to use subprocess.Popen in a few cases anyway.  
>> I'll try that and see what we can do.  Thanks for the note on "grpc within 
>> grpc"; that may simplify some things too.
>>
>> On Tuesday, December 18, 2018 at 1:07:00 PM UTC-6, Eric Gribkoff wrote:
>>>
>>>
>>>
>>> On Tue, Dec 18, 2018 at 10:45 AM  wrote:
>>>
 Thanks, Eric.  That makes some degree of sense, although there are a 
 few cases we still won't be able to deal with, I suspect (and we may have 
 trouble later anyway... in some cases our server program has to shell out 
 to run a separate program, and if that runs into the fork trouble and 
 can't 
 be supported by GRPC we may be stuck with a very clanky REST 
 implementation).


>>> Sorry, I should have been more precise in my earlier response: you are 
>>> fine to use fork+exec (e.g., subprocess.Popen) to run a separate program in 
>>> a new shell. (Caveat: we had a bug 
>>>  that may cause problems 
>>> even with fork+exec when using Python3. The fix is now merged and will be 
>>> in the next release; our nightly builds will also include the fix ~tomorrow 
>>> if you are hitting this issue). The issues on the server-side with fork 
>>> arise when using libraries that fork and, rather than exec'ing a new 
>>> program, continue to run the original program in the child process, e.g., 
>>> Python's multiprocessing module.
>>>
>>>  
>>>
 Hmm, quite a pickle.  I can see I'll be playing with a bunch of toy 
 problems for a bit before even considering doing a migration to GRPC.  
 Most 
 disagreeable, but we'll see what we get.

 Can grpc client stubs be used from within grpc servicers?  (imagining 
 fracturing this whole thing into microservices even if that doesn't solve 
 this particular problem).

>>>
>>> Absolutely, and that's an intended/common usage.
>>>
>>> Thanks,
>>>
>>> Eric
>>>  
>>>

 On Tuesday, December 18, 2018 at 12:32:15 PM UTC-6, Eric Gribkoff wrote:
>
>
>
> On Tue, Dec 18, 2018 at 10:17 AM  wrote:
>
>> Hmm; I'm having some luck looking at the context, which quite happily 
>> changes from is_active() to not is_active() the instant I kill the 
>> waiting 
>> client.  So I thought I'd proceed with something like
>>
>> while not my_future.done():
>>   if not context.is_active():
>> my_future.cancel()
>>
>>
> Consider using add_callback 
>  on 
> the RpcContext instead, so you don't have to poll.
>  
>
>> Terminating the worker thread/process is actually vexing me though!  
>> I tried having a ThreadPoolExecutor to give me a future for the worker 
>> task, but you can't really cancel a future from a thread, it turns out 
>> (you 
>> can only cancel it if it hasn't started running; once it's started, it 
>> still goes to completion).  So I've tried having a separate 
>> ProcessPoolExecutor (maybe processes can be killed?) but that's not 
>> actually going so well either, as attempts to use that to generate 
>> futures 
>> results in some odd "Failed accept4: Invalid Argument" errors which I 
>> can't 
>> quite work through.
>>
>>
> ProcessPoolExecutor will fork subprocesses, and gRPC servers (and many 
> other multi-threaded libraries) are not compatible with this. There is 
> some 
> discussion around this in https://github.com/grpc/grpc/issues/16001. 
> You could pre-fork (fork before creating the gRPC server), but I don't 
> think this will help with your goal of cancelling long-running jobs. It's 
> difficult to cleanly kill subprocesses, as they may be in the middle of 
> an 
> operation that you would really like to clean up gracefully.
>  
>
>> Most confusing.  I wonder if I'll need to subclass grpc.server or if 
>> my ser

Re: [grpc-io] Kill server task if client disconnects? (python)

[liburdi . joshua]

Out of curiosity, can anyone show an example of how add_callback can be 
used to interrupt the server-side process? I have the same problem as the 
OP for my application -- server-side can run for a very long time and if 
the client times out, then I need the server to cancel immediately. I've 
tried a variety of techniques, but I cannot get the callback function to 
stop the server-side call.

On Tuesday, December 18, 2018 at 12:51:23 PM UTC-8, vbp...@gmail.com wrote:
>
> Ah; thanks--we're having to use subprocess.Popen in a few cases anyway.  
> I'll try that and see what we can do.  Thanks for the note on "grpc within 
> grpc"; that may simplify some things too.
>
> On Tuesday, December 18, 2018 at 1:07:00 PM UTC-6, Eric Gribkoff wrote:
>>
>>
>>
>> On Tue, Dec 18, 2018 at 10:45 AM  wrote:
>>
>>> Thanks, Eric.  That makes some degree of sense, although there are a few 
>>> cases we still won't be able to deal with, I suspect (and we may have 
>>> trouble later anyway... in some cases our server program has to shell out 
>>> to run a separate program, and if that runs into the fork trouble and can't 
>>> be supported by GRPC we may be stuck with a very clanky REST 
>>> implementation).
>>>
>>>
>> Sorry, I should have been more precise in my earlier response: you are 
>> fine to use fork+exec (e.g., subprocess.Popen) to run a separate program in 
>> a new shell. (Caveat: we had a bug 
>>  that may cause problems even 
>> with fork+exec when using Python3. The fix is now merged and will be in the 
>> next release; our nightly builds will also include the fix ~tomorrow if you 
>> are hitting this issue). The issues on the server-side with fork arise when 
>> using libraries that fork and, rather than exec'ing a new program, continue 
>> to run the original program in the child process, e.g., Python's 
>> multiprocessing module.
>>
>>  
>>
>>> Hmm, quite a pickle.  I can see I'll be playing with a bunch of toy 
>>> problems for a bit before even considering doing a migration to GRPC.  Most 
>>> disagreeable, but we'll see what we get.
>>>
>>> Can grpc client stubs be used from within grpc servicers?  (imagining 
>>> fracturing this whole thing into microservices even if that doesn't solve 
>>> this particular problem).
>>>
>>
>> Absolutely, and that's an intended/common usage.
>>
>> Thanks,
>>
>> Eric
>>  
>>
>>>
>>> On Tuesday, December 18, 2018 at 12:32:15 PM UTC-6, Eric Gribkoff wrote:



 On Tue, Dec 18, 2018 at 10:17 AM  wrote:

> Hmm; I'm having some luck looking at the context, which quite happily 
> changes from is_active() to not is_active() the instant I kill the 
> waiting 
> client.  So I thought I'd proceed with something like
>
> while not my_future.done():
>   if not context.is_active():
> my_future.cancel()
>
>
 Consider using add_callback 
  on 
 the RpcContext instead, so you don't have to poll.
  

> Terminating the worker thread/process is actually vexing me though!  I 
> tried having a ThreadPoolExecutor to give me a future for the worker 
> task, 
> but you can't really cancel a future from a thread, it turns out (you can 
> only cancel it if it hasn't started running; once it's started, it still 
> goes to completion).  So I've tried having a separate ProcessPoolExecutor 
> (maybe processes can be killed?) but that's not actually going so well 
> either, as attempts to use that to generate futures results in some odd 
> "Failed accept4: Invalid Argument" errors which I can't quite work 
> through.
>
>
 ProcessPoolExecutor will fork subprocesses, and gRPC servers (and many 
 other multi-threaded libraries) are not compatible with this. There is 
 some 
 discussion around this in https://github.com/grpc/grpc/issues/16001. 
 You could pre-fork (fork before creating the gRPC server), but I don't 
 think this will help with your goal of cancelling long-running jobs. It's 
 difficult to cleanly kill subprocesses, as they may be in the middle of an 
 operation that you would really like to clean up gracefully.
  

> Most confusing.  I wonder if I'll need to subclass grpc.server or if 
> my servicer can manually run a secondary process or some such.  
>
> Still, surprising to me this isn't a solved problem built into GRPC.  
> I feel like I'm missing something really obvious.
>
>
 I wouldn't consider cancelling long running jobs spawned by your server 
 as part of the functionality that gRPC is intended for - this is a task 
 that can came up regardless of what server protocol you are using, and 
 will 
 arise often even on non-server applications. A standard approach for this 
 in a multi-threaded environment would be setting a cancel boolean variable 
 (e.g., 

[grpc-io] (gRPC-java) How to limit thread pool size for blocking stub?

[Zareen Syed]

Hi,

The method withExecutor() in AbstractStub class mentions that "setting this 
option may not take effect for blocking calls", is there any other way to 
configure the number of threads used by the client blocking stub?

Thanks,
Zareen.

-- 
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/330ddaff-c586-4797-a722-68db7d66ea9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: how to detect version of gRPC?

[hemantietf]

Ok, thanks!

On Thursday, February 28, 2019 at 6:29:36 PM UTC-5, Nicolas Noble wrote:
>
> gRPC isn't a software you run, it's a library. As such, there's no 
> "command" to run.
>
> You can get an std::string with the version using the call grpc::Version();
>
> *From: *>
> *Date: *Thu, Feb 28, 2019 at 2:51 PM
> *To: *grpc.io
>
> c++
>>
>> thanks.
>>
>> On Thursday, February 28, 2019 at 1:49:28 PM UTC-5, Carl Mastrangelo 
>> wrote:
>>>
>>> What language are you using?
>>>
>>> On Thursday, February 28, 2019 at 7:43:51 AM UTC-8, heman...@gmail.com 
>>> wrote:

 I downloaded gRPC for use from github.  How do I find out what version 
 of gRPC this software is?  I don't see a VERSION file with the software.  

 For example, with protobuf, I can use 'protoc --version` to find out 
 the version of protobuf I am using.

 Best,

 Hemant

>>> -- 
>> 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/4701a223-36f1-4f2b-af64-00d1e088962c%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/8c05a26c-a221-4b1e-aa91-018dafa704de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: how to detect version of gRPC?

['Nicolas Noble' via grpc.io]

gRPC isn't a software you run, it's a library. As such, there's no
"command" to run.

You can get an std::string with the version using the call grpc::Version();

*From: *
*Date: *Thu, Feb 28, 2019 at 2:51 PM
*To: *grpc.io

c++
>
> thanks.
>
> On Thursday, February 28, 2019 at 1:49:28 PM UTC-5, Carl Mastrangelo wrote:
>>
>> What language are you using?
>>
>> On Thursday, February 28, 2019 at 7:43:51 AM UTC-8, heman...@gmail.com
>> wrote:
>>>
>>> I downloaded gRPC for use from github.  How do I find out what version
>>> of gRPC this software is?  I don't see a VERSION file with the software.
>>>
>>> For example, with protobuf, I can use 'protoc --version` to find out the
>>> version of protobuf I am using.
>>>
>>> Best,
>>>
>>> Hemant
>>>
>> --
> 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/4701a223-36f1-4f2b-af64-00d1e088962c%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/CAOWnRi-exiURzCWhtJJkrMQ5WW4t3NPG6rJyaQC01omCoYVexQ%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 detect version of gRPC?

[hemantietf]

c++

thanks.

On Thursday, February 28, 2019 at 1:49:28 PM UTC-5, Carl Mastrangelo wrote:
>
> What language are you using?
>
> On Thursday, February 28, 2019 at 7:43:51 AM UTC-8, heman...@gmail.com 
> wrote:
>>
>> I downloaded gRPC for use from github.  How do I find out what version of 
>> gRPC this software is?  I don't see a VERSION file with the software.  
>>
>> For example, with protobuf, I can use 'protoc --version` to find out the 
>> version of protobuf I am using.
>>
>> Best,
>>
>> Hemant
>>
>

-- 
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/4701a223-36f1-4f2b-af64-00d1e088962c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Vijay Pai' via grpc.io]

So several months ago, we started considering ongoing directions for 
evolving the C++ API. Certainly, a major concern was that it is difficult 
to use the async CQ-based API. If you've been following the repo recently, 
though, you see that we're headed in a direction of a callback-based API. 

As much as some of us (including me) wanted to base a system on futures, 
there hasn't yet been an acceptance of the C++ concurrency TS into an ISO 
standard for C++, and the C++11 futures API is just too limited to be 
practical. We also considered using futures from an external library but 
were concerned about not only introducing an extra dependence but also the 
likelihood that that would lead to a bifurcation in development practices 
when a reasonable future implementation reaches the C++ standard.

So, among the options that we considered, the callback-based API seemed 
most practical, usable, and ready for use. That said, it's still 
experimental for the time being, with a plan of making it generally 
available in the next few months. In the meanwhile, please feel free to 
look over the API and tests.

https://grpc.io/grpc/cpp/namespacegrpc_1_1experimental.html (which also 
includes other features)
https://github.com/grpc/grpc/blob/master/test/cpp/end2end/client_callback_end2end_test.cc
 
(which tests the client-side of the callback API)
https://github.com/grpc/grpc/blob/master/test/cpp/end2end/test_service_impl.cc 
(which tests the server-side of the sync and callback APIs)

- Vijay

On Thursday, February 28, 2019 at 2:01:06 AM UTC-8, Lei Wang wrote:
>
> Also see proposal https://github.com/grpc/grpc/issues/18204
>
> On Thursday, February 28, 2019 at 3:32:27 PM UTC+8, Lei Wang wrote:
>>
>> 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/5db40fbe-bfac-467d-93ce-2e588ef38d6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Srini Polavarapu' via grpc.io]

Details are posted 
 now.

On Wednesday, February 27, 2019 at 9:58:18 PM UTC-8, Srini Polavarapu wrote:
>
> 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/dd53f352-6f64-4b61-b67b-62e52fbc3f4a%40googlegroups.com.
For more options, visit https://groups.google.com

[grpc-io] Evolution of gRPCLB

['Srini Polavarapu' via grpc.io]

If you are using gRPCLB 
,
 
please read on:

gRPC team is working on evolving the current gRPCLB functionality. We will 
be moving away from our custom load balancing protocol and adopting xDS 
Protocol 
 
based on Envoy xDS API 
. 
This will allow interoperability with open source control planes that 
support the xDS API, such as Istio Pilot 
, go-control-plane 
 and java-control-plane 
. Other improvements 
include a more flexible and improved load balancing policy configuration 
 and 
load reporting based on LRS 

 
(load reporting service).

The client-side implementation of xDS load balancing plugin will not be 
compatible with the current gRPCLB protocol. Hence, the current gRPCLB 
implementation can be considered deprecated. We are actively working on the 
implementation of the new protocol. Expect to see a lot of progress in the 
coming quarters, including a gRFC on the new design. If you are relying on 
the current implementation in any way, please comment here so we can figure 
out an appropriate time to remove it after the new implementation is ready.

-- 
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/4c98eedb-5f65-4ade-b4e7-0798733548de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: How to create a 2-way authentified connection between nodes ? (C#)

['Jan Tattermusch' via grpc.io]

I'm not sure I fully understand, but it seems there's a bit of trying to 
reinvent the wheel.
what options you have:

- You can create a mutual authenticated secure channel with gRPC. That 
means both client and server will authenticate each other with a public and 
private key  (under "normal" circumstances, only the client checks that the 
server knows the private key). This can be setup using additional arguments 
in SslCredentials and SslServerCredentials.

- if you decide to use "custom" authentication, the usual way to do that is 
to create a secure channel (this time without mutual authentication) and 
then the client send an authentication token (e.g. a JWT) along with each 
request in the RPC headers.


On Monday, February 25, 2019 at 12:35:18 PM UTC+1, BobFrancis wrote:
>
>
> Hi, 
>
> I’ve been using gRPC, in C#, for one of my projects and trying to achieve 
> the following: an authentified P2P link (essentially a 2-way connection) 
> between 2 nodes.  
>
> This is currently how I set up the connection: one node has the listening 
> address of the other peers gRPC server and when this node starts it creates 
> a channel to the other. Right after creating the Channel it calls an “Auth( 
> )” method exposed by the other peers service, which will also create a 
> Channel to the first node, so: 
>
>1. Dial peer.  
>2. Call Auth ( auth data ) method 
>3. On the other node, create a channel to the caller (he transmits his 
>listening address) 
>
> Note that the Auth method takes a pub key and a signature that will be 
> verified by the other peer: this is my custom auth logic. One problem is 
> that I’m not sure how to link subsequent calls to the authentified channel 
> (actually the channel doesn’t matter to much, what’s more important is to 
> know that the sender of a message has already been authentified), because 
> the only info I seem to have is ServerCallContext.Peer and I seriously 
> doubt that it can be used. 
>
> So my questions: 
> 1 - Is it ok to create a Channel inside one of the servers service methods 
> ? 
>

Yes, that's fine.
 

> 2 - How can I securely link the Channel to auth data ? In other words when 
> someone calls one of the peers service methods, I need to able to link it 
> to a peer has previously been autentified. 
>
> Thanks in advance
>

-- 
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/36513891-a096-47c6-bded-089c69d4869f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRPC Java 1.19.0 Released

['Carl Mastrangelo' via grpc.io]

gRPC Java 1.19.0 is now released.   It should be ready use from Maven 
Central and JCenter.

https://github.com/grpc/grpc-java/releases/tag/v1.19.0

Dependencies and Build Changes
   
   - Upgraded to protobuf 3.6.1 (#5320 
   )
   - Google App Engine Java 7 is no longer supported, as it was shut down 
   . Java 8 is 
   supported.
   - Upgraded Guava to 26.0-android
   - Add "fake" Bazel dependency on Guava's failureaccess to fix dependency 
   handling issue in maven_jar (#5350 
   )
   - Upgraded OpenCensus to v0.19.2 (#5329 
   )

Bug Fixes
   
   - Fixed Service Config DNS parsing to match specification (Service 
   Config is still off by default) (#5293 
   )
   - OkHttp no longer spams NPE when connecting to a server that's down (
   #5260 )
   - Context avoids leaking ClassLoader through a ThreadLocal (#5290 
   )
   - Status is now preserved when getting a RST_STREAM with no error (#5264 
   )
   - Removed Channel reference from ManagedChannelWrapper to avoid a memory 
   leak (#5283 )
   - Avoid NPE in Cronet after the transport has shutdown (#5275 
   )
   - Fixed a channel panic caused by calling NameResolver.refresh() (#5223 
   )

New Features
   
   - New artifact grpc-bom is added (#5209 
   )
   - Each ManagedChannel can now have its own ProxyDetector (#5173 
   )

Behavior Changes
   
   - If enabled, health checking defaults to SERVING if the name 
   unspecified (#5274 )
   - Graceful Netty server shutdown now issues two GOAWAYs (#5351 
   )
   - Client-side health checking now warns if disabled (#5261 
   )

API Changes
   
   - Removed DEFAULT_CONNECTION_SPEC from OkHttpChannelBuilder (#5309 
   )
   - NettyChannelBuilder now accepts a channelFactory (#5312 
   )
   - NettyServerBuilder supports listening on multiple sockets (#5306 
   )
   - CallCredentials is now preferred over CallCredentials2 (#5216 
   )
   - ProxiedSocketAddress is added as an Experimental API (#5344 
   )
   - Added NameResolver.Helper, for use with new 
   NameResolver.newNameResolver() overload (#5345 
   )
   - Deprecated previous NameResolver.newNameResolver() overload (#5345 
   )

Documentation
   
   - SECURITY.md 
    recommendations 
   updated and reorganized (#5281 
   )

Acknowledgments

Thanks to all of our contributors:

   - Arajit Samanta @arajitsamanta 
   - Bogdan Drutu @bogdandrutu 
   - Danna Kelmer @dkelmer 
   - Ignacio del Valle Alles @idelvall 
   - Michael Plump @plumpy 
   - Tim van der Lippe @TimvdLippe 
   - Yang Song @songy23 
   - kenji yoshida @xuwei-k 

-- 
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/fffbea17-9c19-4d7d-9697-a19bc54f4e0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: how to detect version of gRPC?

['Carl Mastrangelo' via grpc.io]

What language are you using?

On Thursday, February 28, 2019 at 7:43:51 AM UTC-8, heman...@gmail.com 
wrote:
>
> I downloaded gRPC for use from github.  How do I find out what version of 
> gRPC this software is?  I don't see a VERSION file with the software.  
>
> For example, with protobuf, I can use 'protoc --version` to find out the 
> version of protobuf I am using.
>
> Best,
>
> Hemant
>

-- 
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/cd8fa89a-a0ad-40fe-b94d-1d153a289de9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Unimplemented Method on Linux / Windows

['Carl Mastrangelo' via grpc.io]

That sounds like a bug in your code.  That error would not be raised by 
changing JVMs.

On Thursday, February 28, 2019 at 6:11:54 AM UTC-8, marcel.moehring wrote:
>
> Hello,
>
>  
>
> we are currently migrating projects to JDK 11 and are experiencing the 
> strange problem where JARs compiled on macOS do not longer work on Linux or 
> Windows.
>
> For every request the server answers with UNIMPLEMENTED “Method not found”.
>
>  
>
> The only native parts we know of are tcnative and when compiling we use 
> the compile target arch (or the uber jar for testing).
>
>  
>
> Any ideas?
>
>  
>
>  
>
> Thanks,
>
> Marcel
>
>  
>

-- 
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/884713ef-7f43-439b-8c5a-368cf913dadb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] how to detect version of gRPC?

[hemantietf]

I downloaded gRPC for use from github.  How do I find out what version of 
gRPC this software is?  I don't see a VERSION file with the software.  

For example, with protobuf, I can use 'protoc --version` to find out the 
version of protobuf I am using.

Best,

Hemant

-- 
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/dccdb7dd-699e-4a84-91d5-58cfac77b975%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Unimplemented Method on Linux / Windows

[Marcel Möhring]

Hello,

we are currently migrating projects to JDK 11 and are experiencing the strange 
problem where JARs compiled on macOS do not longer work on Linux or Windows.
For every request the server answers with UNIMPLEMENTED “Method not found”.

The only native parts we know of are tcnative and when compiling we use the 
compile target arch (or the uber jar for testing).

Any ideas?


Thanks,
Marcel

-- 
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/EB9D6ED9-DE16-4EA2-8BC6-C1E76C336A13%40catapullt.de.
For more options, visit https://groups.google.com/d/optout.

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

[Lei Wang]

Also see proposal https://github.com/grpc/grpc/issues/18204

On Thursday, February 28, 2019 at 3:32:27 PM UTC+8, Lei Wang wrote:
>
> 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/03338688-bf0f-4c58-bf56-690fffa97ea3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.