Re: [grpc-io] gRFC L65: Additional PyPI Packages for gRPC Python

[Kailash Sethuraman]

To clarify, I am suggesting that you consider solving the package name
confusion by using the gRPC name for a meaningful package that does not
exist yet. Another positive with this approach is that its intuitive -  "if
I type pip install grpc, I expect to get a working gRPC package
installed."  You can err this package toward sane defaults and depend on
protobuf too - 99% of your users use it with protobuf anyways..



On Thu, May 14, 2020 at 1:32 PM 'Lidi Zheng' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Richard had an idea that we could create a bundle named
> `grpcio[protobuf]`, which includes peripheral packages. After all, gRPC
> team wants to keep the implementation agnostic to codec, so they weren't
> packed into the main package.
>
> It's a good idea, this gRFC is for package name confusion. For the new
> bundle package, I can start another proposal.
>
> On Wednesday, May 13, 2020 at 8:18:51 PM UTC-7 hsa...@gmail.com wrote:
>
>> Have you considered using the name for a new meta-package bundle for
>> related packages?
>>
>>- grpcio
>>- grpcio-status
>>- grpcio-channelz
>>- grpcio-reflection
>>- grpcio-health-checking
>>-
>>
>> Or even a kitchen sink package that includes grpcio-testing and
>> grpcio-tools.
>>
>> On Wed, May 13, 2020 at 7:32 PM 'Lidi Zheng' via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>>> Abstract:
>>>
>>> gRPC Python is uploaded as "grpcio" on PyPI, but there is another
>>> package named "grpc". Hence, some users are confused. This document
>>> proposes to upload additional packages named "grpc" and "grpc-*" to guide
>>> users to official packages.
>>>
>>> gRFC:
>>> https://github.com/lidizheng/proposal/blob/L65-python-package-name/L65-python-package-name.md
>>> PR: https://github.com/grpc/proposal/pull/177
>>>
>>> --
>>> 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 view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/482e22f0-4044-4f7e-81b9-179f70ac5be5%40googlegroups.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/8567af8c-0404-40c4-8dcd-d44fa9008c46%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAFEPE9TcrFj8fRgomOh4UCL%2Bns8vaV%2Bui7dzmL8AvwmOMso42A%40mail.gmail.com.

Re: [grpc-io] Re: CreateInsecureChannelFromFd() - ownership of the given file descriptor.

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

What I said earlier is correct: once you pass an fd
to CreateInsecureChannelFromFd(), you should not close it, because the
channel has already taken ownership of it.  But it sounds like the question
you're actually asking here is about why the channel doesn't automatically
reconnect.

When you create a normal channel via CreateChannel(), you get a full client
channel that contains all the logic for name resolution, load balancing,
and connection management.  Since it contains the code to create the fd for
each connection, it can automatically create new connections as needed; if
the connection to a given address fails, it can try to establish a new
connection.

In contrast, when you use CreateInsecureChannelFromFd(), you are creating
what is called a "direct" channel.  Direct channels do not do name
resolution, load balancing, or any connection management; they have just
the one fd that you created, and when that fd no longer works, the channel
is no longer usable.  A direct channel cannot automatically create a new
connection when the fd you gave it fails, because it has no idea how you
created the connection in the first place -- all it was given is the
already-created fd.  So if the connection fails, you have to create a whole
new channel by creating a new fd and passing it to
CreateInsecureChannelFromFd() again.

You say that you tried calling CreateInsecureChannelFromFd() again and that
you ran into assertion errors, but I don't know why that would happen.  If
you can share your code and the assertion error you're seeing, maybe we can
help tell you what's wrong.

On Wed, May 13, 2020 at 1:21 PM Krzysztof Rybak 
wrote:

> So what is the proper way to run grpc based on fd-s ? I use grpc tagged
> v1.19.1.
> The problem is that when I release the fd on the client side
> in CreateInsecureChannelFromFd(), the client doesn't reconnect when server
> is restarted. From strace log: the client does a shutdown() on the given fd
> and doesn't recover from that state.
>
> In my application I do close() on the fd passed to
> CreateInsecureChannelFromFd(), create a new socket and pass it to
> CreateInsecureChannelFromFd(), but from the previous response this is not a
> solution.
> I also tried (on client side) not to close the passed fd, but create a new
> socket and pass fd to CreateInsecureChannelFromFd() - this caused assertion
> errors on grpc.
> Also tried just leave it without any handling but looks like grpc client
> cannot recover in case of for example server restart.
>
> The simple example with one client (based on helloworld example) is below,
> is that way correct? (I omitted intentionally checking return codes and
> other part of the program).
>
> server side:
>
>   int server_fd;
>   struct sockaddr_in address;
>
>   server_fd = socket(AF_INET, SOCK_STREAM, 0);
>
>   address.sin_family = AF_INET;
>   address.sin_addr.s_addr = INADDR_ANY;
>   address.sin_port = htons(PORT);
>
>   bind(server_fd, (struct sockaddr *)&address, sizeof(address);
>   listen(server_fd, 0);
>
>   int flags = fcntl(server_fd, F_GETFL);
>   fcntl(server_fd, F_SETFL, flags | O_NONBLOCK);
>
>   GreeterServiceImpl service;
>   ServerBuilder builder;
>   builder.RegisterService(&service);
>   std::unique_ptr server(builder.BuildAndStart());
>
>   int client_fd = -1;
>   while(1){
> client_fd = accept(server_fd, nullptr, nullptr);
> if (client_fd == -1 ) continue;
>
> flags = fcntl(client_fd, F_GETFL);
> fcntl(client_fd, F_SETFL, flags | O_NONBLOCK);
>   
> ::grpc::AddInsecureChannelFromFd(server.get(), client_fd);
>
>   }
>
>
> client side:
>   int client_fd;
>   struct sockaddr_in serv_addr;
>
>   client_fd = socket(AF_INET, SOCK_STREAM, 0);
>
>   serv_addr.sin_family = AF_INET;
>   serv_addr.sin_port = htons(PORT);
>
>   inet_pton(AF_INET, "127.0.0.1", &serv_addr.sin_addr);
>
>   connect(client_fd, (struct sockaddr *)&serv_addr, sizeof(serv_addr));
>
>   int flags = fcntl(client_fd, F_GETFL);
>   fcntl(client_fd, F_SETFL, flags | O_NONBLOCK);
>
>   auto channel = 
> grpc::CreateInsecureChannelFromFd(Greeter::service_full_name(), client_fd);
>
> GreeterClient greeter(channel);
>
>   while (1){
> // calling SayHello -> stub->SayHello and when status is not ok, should I 
> handle it?
>   }
>
>
> W dniu środa, 6 maja 2020 19:36:44 UTC+2 użytkownik Mark D. Roth napisał:
>>
>> gRPC takes ownership of the fd when you pass it to
>> CreateInsecureChannelFromFd(), so you don't need to shut it down or close
>> it.
>>
>> On Tuesday, May 5, 2020 at 4:33:23 AM UTC-7 krzyszt...@gmail.com wrote:
>>
>>> Hi,
>>> I'm creating a grpc channel for the grpc client using
>>> function CreateInsecureChannelFromFd() and giving the file descriptor to
>>> it.
>>> Should I handle the connection for the given file descriptor afterwards
>>> in application or is it handled in grpc framework?
>>>
>>> For example on application side when messages are not delivered I
>>> reconnect using shutdown() or close() etc.
>>> Is it necessary? Fr

[grpc-io] Android tutorial: Confusion with Android clients and asynchronicity

[theotherkwb]

To the point:  there are a couple of things I've noticed on 
https://grpc.io/docs/tutorials/basic/android/ that have probably added to 
my own confusion, and I certainly didn't need anything to increase it.  

One is the mention of SettableFuture in the description, though it is not 
anywhere in the code.  
The other is the final section discussing the "*response *stream observer" 
when it was actually talking about the *request *stream observer.  

It's not intended to be an exhaustive list, and I suspect that there are 
plenty of other errors given the glaring aspect of that first one.

Normally I wouldn't mind fixing things myself, but the truth is, I still 
don't understand how to deal with asynchronicity correctly in Android, 
especially with bidirectional streaming procedures, and mostly because I am 
totally new to the entire and overwhelmingly confused/confusing API of 
Android related to concurrency.

In fact, I've been trying to wrap my stub code for a bidirectional 
streaming procedure in a layer that provides ListenableFutures of some 
sort, and -- egads -- it has been a nightmare trying to figure that out.  
But that's *my own* problem due to unfamiliarity with the platform.  I've 
been very impressed with gRPC otherwise, and had no difficulty at all 
figuring out how to deal with asynchronicity in my C# client, where there 
seems to be no need whatsoever to add a layer on top of the stub code.  
Then came Android.  Blech.  :-)

By contrast, the tutorial's gaffs are more of a *community *problem, so if 
someone wants to take the time to clear it up, that would be nice.  Sorry 
if this is not the right place to offer such well-intended feedback -- I 
just couldn't find any more appropriate route for it.  This is more of a 
notification message than a question of any kind, so I'm not necessarily 
looking for anyone to reply.  Thanks.

Regards,
-- 
Keith W. Blackwell

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/52accad5-856e-44fb-a64b-c45964d38a4c%40googlegroups.com.

Re: [grpc-io] gRFC L65: Additional PyPI Packages for gRPC Python

['Lidi Zheng' via grpc.io]

Richard had an idea that we could create a bundle named `grpcio[protobuf]`, 
which includes peripheral packages. After all, gRPC team wants to keep the 
implementation agnostic to codec, so they weren't packed into the main 
package.

It's a good idea, this gRFC is for package name confusion. For the new 
bundle package, I can start another proposal.

On Wednesday, May 13, 2020 at 8:18:51 PM UTC-7 hsa...@gmail.com wrote:

> Have you considered using the name for a new meta-package bundle for 
> related packages?
>
>- grpcio
>- grpcio-status
>- grpcio-channelz
>- grpcio-reflection
>- grpcio-health-checking
>- 
>
> Or even a kitchen sink package that includes grpcio-testing and 
> grpcio-tools. 
>
> On Wed, May 13, 2020 at 7:32 PM 'Lidi Zheng' via grpc.io <
> grp...@googlegroups.com> wrote:
>
>> Abstract:
>>
>> gRPC Python is uploaded as "grpcio" on PyPI, but there is another package 
>> named "grpc". Hence, some users are confused. This document proposes to 
>> upload additional packages named "grpc" and "grpc-*" to guide users to 
>> official packages.
>>
>> gRFC: 
>> https://github.com/lidizheng/proposal/blob/L65-python-package-name/L65-python-package-name.md
>> PR: https://github.com/grpc/proposal/pull/177
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/482e22f0-4044-4f7e-81b9-179f70ac5be5%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8567af8c-0404-40c4-8dcd-d44fa9008c46%40googlegroups.com.

Re: [grpc-io] Re: Grpc excessive default memory usage

['Eric Gribkoff' via grpc.io]

Thanks for the additional information.

On Wed, May 13, 2020 at 11:41 PM  wrote:

> Thanks Eric for the reply.
>
> Couple of things. I am not able to get this when you say that gRPC java is
> not optimized for this type of large file. My individual message size is
> 1024 bytes only. The program reads this much bytes from the file at a time
> and sends this to onNext() call of stream observer. So, each message sent
> on wire for each onNext() must be little over 1kb only.
>

That makes sense; what I was considering as a possibility was that the
messages were going to onNext() *much* faster than they were going out on
the wire. In the worst case, the entire file would be buffered into memory
before anything was sent over the wire.

>
> Also, I just changed the gRPC version to *1.29.0* and saw that the native
> memory usage is almost zero with this version. The high usage that I saw
> was on version *1.21.0*.
>
>
Even better; most likely the memory usage was optimized or, if a leak,
fixed since version 1.21.

Thanks for the update!

Eric


> Regards,
>
> On Thursday, May 14, 2020 at 3:26:12 AM UTC+5:30, Eric Gribkoff wrote:
>>
>> gRPC Java may not be optimized for this type of large file transfer, and
>> is likely copying the provided bytes more than once which could explain why
>> you see additional direct memory allocation. These should be all released
>> once the data goes out over the wire. It looks from your code snippet that
>> the entire file is immediately buffered - we would expect to see the memory
>> consumption decrease as bytes are sent out to the client.
>>
>> Further investigation of this would probably be best carried out on the
>> grpc java repository at https://github.com/grpc/grpc-java/ if you'd care
>> to file an issue/reproduction case there.
>>
>> Thanks,
>>
>> Eric
>> On Monday, May 11, 2020 at 3:22:35 AM UTC-7 ravi@gmail.com wrote:
>>
>>> I have been testing gRPC behaviour for larger message size on my
>>> machine. I have got a single client to which I am streaming a video file of
>>> 603mb via streaming gRPC. I ran into OOM while testing and found that in
>>> case of slow clients, response messages were getting queued up and I was
>>> getting below error msg:
>>> io.netty.util.internal.OutOfDirectMemoryError: failed to allocate
>>> 16777216 byte(s) of direct memory (used: 1873805512, max: 1890582528)
>>>
>>>
>>> Now this is fixable via flow control(using onReady() channel handler)
>>> but out of curiosity I increased my direct memory to 4GB
>>> via -XX:MaxDirectMemorySize=4g  jvm flag to force queuing up of all
>>> response messages and hence the client can consume on it's own pace. It got
>>> completed successfully. But I observed that I ended up using 2.4GB of
>>> direct memory. I checked it via usedDirectMemory() eposed by netty
>>> for ByteBufAllocatorMetric.
>>>
>>> *Isn't this too much for a 603mb file as it is 3 times more than the
>>> total file size*. Below is the code snippet that I am using:
>>>
>>> stream = new FileInputStream(file);
>>> byte[] buffer = new byte[1024];
>>> ByteBufAllocator byteBufAllocator = ByteBufAllocator.DEFAULT;
>>> int length;
>>> while ((length = stream.read(buffer)) > 0) {
>>>  response.onNext(VideoResponse.newBuilder().setVideoBytes(ByteString.
>>> copyFrom(buffer)).build());
>>>  if (ByteBufAllocator.DEFAULT instanceof ByteBufAllocatorMetricProvider)
>>> {
>>> ByteBufAllocatorMetric metric = ((ByteBufAllocatorMetricProvider
>>> ) byteBufAllocator).metric();
>>> System.out.println(metric.usedDirectMemory()/(1024*1024));
>>> }
>>> }
>>>
>>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/e9584663-f06e-4a22-9307-520409511eab%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CALUXJ7gCp6b1noZGBbBQqMqDjsFrNhnTMonN%2BHmrEWQQGGh0kg%40mail.gmail.com.