Re: [grpc-io] grpc executor threads

[Jeff Steger]

Hi AJ,

Thanks for the reply. May I suggest making max number of threads (and/or
any rate limits) configurable.

Jeff

On Tue, May 16, 2023 at 7:44 PM 'AJ Heller' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hello all, I want to offer a quick update. tl;dr: Jeff's analysis is
> correct. The executor is legacy code at this point, slated for deletion,
> and increasingly unused.
>
> We have been carefully replacing the legacy I/O, timer, and async
> execution implementations with a new public EventEngine
> 
>  API
> and its default implementations. The new thread pools do still auto-scale
> as needed - albeit with different heuristics, which are evolving as we
> benchmark - but threads are now reclaimed if/when gRPC calms down from a
> burst of activity that caused the pool to grow. Also, I believe the
> executor did not rate limit thread creation when closure queues reached
> their max depths, but the default EventEngine implementations do rate limit
> thread creation (currently capped at 1 new thread per second, but that's an
> implementation detail which may change ... some benchmarks have shown it to
> be a pretty effective rate). Beginning around gRPC v.148, you should see an
> increasing number of "event_engine" threads, and a decreasing number of
> executor threads. Ultimately we aim to unify all async activity into a
> single auto-scaling thread pool under the EventEngine.
>
> And since the EventEngine is a public API, any integrators that want
> complete control over thread behavior can implement their own EventEngine
> and plug it in to gRPC. gRPC will (eventually) use a provided engine for
> all async execution, timers, and I/O. Implementing an engine is not a small
> task, but it is an option people have been requesting for years. Otherwise,
> the default threading behavior provided by gRPC is tuned for performance -
> if starting a thread helps gRPC move faster, then that's what it will do.
>
> Hope this helps!
> -aj
>
> On Friday, May 12, 2023 at 4:03:58 PM UTC-7 Jiqing Tang wrote:
>
>> Thanks so much Jeff, agree reaping them after they being idle would be
>> great.
>>
>> On Friday, May 12, 2023 at 6:59:28 PM UTC-4 Jeff Steger wrote:
>>
>>> This is as close to an explanation as I have found:
>>>
>>> look at sreecha’s response in
>>> https://github.com/grpc/grpc/issues/14578
>>>
>>> tldr:
>>> “ The max number of threads can be 2x
>>> 
>>>  the
>>> number cores and unfortunately its not configurable at the moment….. any
>>> executor threads and timer-manager you see are by-design; unless the
>>> threads are more than 2x the number of cores on your machine in which case
>>> it is clearly a bug”
>>>
>>>
>>> From my observation of the thread count and from my examination of the
>>> grpc code (which I admit I performed some years ago), it is evident to me
>>> that the grpc framework spawns threads up to 2x the number of hardware
>>> cores. It will spawn a new thread if an existing thread in its threadpool
>>> is busy iirc. The issue is that the grpc framework never reaps idle
>>> threads. Once a thread is created, it is there for the lifetime if the grpc
>>> server. There is no way to configure the max number of threads either. It
>>> is really imo a sloppy design. threads aren’t free and this framework keeps
>>> (in my case) dozens and dozens of idle threads around even during long
>>> periods of low or no traffic. Maybe they fixed it in newer versions, idk.
>>>
>>> On Fri, May 12, 2023 at 5:58 PM Jiqing Tang  wrote:
>>>
 Hi Jeff and Mark,

 I just ran into the same issue with an async c++ GRPC server (version
 1.37.1), was curious about these default-executo threads and then got this
 thread, did you guys figure out what these threads are for? The number
 seems to be about 2x of the polling worker threads.

 Thanks!

 On Friday, January 7, 2022 at 3:47:51 PM UTC-5 Jeff Steger wrote:

> Thanks Mark, I will turn on trace and see if I see anything odd. I was
> reading about a function called Executor::SetThreadingDefault(bool enable)
> that I think I can safely call after i create my grpc server. It is a
> public function and seems to allow me to toggle between a threaded
> implementation and an async one. Is that accurate? Is calling this 
> function
> safe to do and/or recommended (or at least not contra-recommended). Thanks
> again for your help!
>
> Jeff
>
>
>
> On Fri, Jan 7, 2022 at 11:14 AM Mark D. Roth  wrote:
>
>> Oh, sorry, I thought you were asking about the sync server threads.
>> The default-executor threads sound like threads that are spawned 
>> internally
>> inside of C-core for things like synchronous DNS resolution; those should
>> be completely unrelated to the 

Re: [grpc-io] Re: {method 'next_event' of 'grpc._cython.cygrpc.SegregatedCall' objects} taking >6secs on MacOS

['Zach Reyes' via grpc.io]

Just something we can run and try to reproduce your problem :).

On Wednesday, May 17, 2023 at 5:50:58 PM UTC-4 Adam Walters wrote:

> Hi Zach,
>
> Sorry if this is a stupid question but what all are you looking for this 
> file to contain?
>
> On May 17, 2023, at 3:55 PM, 'Zach Reyes' via grpc.io <
> grp...@googlegroups.com> wrote:
>
> Can you please provide a full reproducible file, rather than a single 
> file. That we the team can benchmark.
>
>
>
> On Tuesday, May 16, 2023 at 1:55:11 PM UTC-4 Adam Walters wrote:
>
>> Hello,
>>
>> Recently my program started running extremely slow and upon further 
>> investigation found that this '{method 'next_event' of 
>> 'grpc._cython.cygrpc.SegregatedCall' objects}' was taking over 5 seconds 
>> per call.
>>
>> I am using all of the latest versions grpc and google-ads packages.
>>
>> Below is an example of the code that is running and the results from a 
>> cProfile run:
>> from google.ads.googleads.client import GoogleAdsClient
>> from google.ads.googleads.v13.services.services.google_ads_service import 
>> pagers
>> import logging
>>
>> logging.basicConfig(level=logging.INFO, format='[%(asctime)s - 
>> %(levelname)s] %(message).5000s')
>> logging.getLogger('google.ads.googleads.client').setLevel(logging.INFO)
>>
>> client = GoogleAdsClient.load_from_storage("google-ads.yaml")
>> google_ads_service = client.get_service("GoogleAdsService", version='v13'
>> )
>>
>> class GoogleQuery:
>> """A class to query Google Ads API
>>
>> Attributes:
>> client: An initialized GoogleAdsClient instance.
>> mcc_id: The Google Ads MCC ID
>> search_accounts_query: A query to return all search accounts
>> display_accounts_query: A query to return all display accounts
>>
>> Methods:
>> get_existing_search_accounts: Returns a dictionary of existing search 
>> accounts
>> get_existing_display_accounts: Returns a dictionary of existing display 
>> accounts
>> run_gaql_query: Runs a GAQL query and returns a Pager object
>> """
>>
>> def __init__(self):
>> self.client = client
>> self.mcc_id = "XX"
>> self.search_accounts_query = """SELECT
>> customer_client.id,
>> customer_client.resource_name,
>> customer_client.descriptive_name,
>> customer_client.manager,
>> customer_client.applied_labels
>> FROM 
>> customer_client
>> WHERE
>> customer_client.manager = false 
>> AND customer_client.id IS NOT NULL 
>> AND customer_client.descriptive_name LIKE '%Search%'
>> AND customer.status = 'ENABLED'"""
>>
>> @staticmethod
>> def run_gaql_query(query: str, customer_id) -> pagers.SearchPager:
>> """runs GAQL query through Google Ads API
>> Args:
>> customer_id: customer ID being queried
>> query: the actual GAQL query being ran
>> Returns:
>> Returns a pagers.SearchPager response of the raw data
>> """
>> return google_ads_service.search(
>> customer_id=customer_id,
>> query=query
>> )
>>
>> def get_existing_search_accounts(self) -> dict:
>> """runs GAQL query through Google Ads API
>>
>> Returns:
>> Returns a dict of {internal_id, account_name}
>> """
>> response = self.run_gaql_query(self.search_accounts_query, self.mcc_id)
>> return {row.customer_client.descriptive_name[-8:]: 
>> row.customer_client.descriptive_name for row in response}
>>
>> gaql = GoogleQuery()
>> gaql.get_existing_search_accounts()
>>
>> # cProfile Results from above code Tue May 16 13:31:28 2023   
>>  output_test.pstats
>>
>>  991213 function calls (973122 primitive calls) in 10.099 seconds
>>
>>Ordered by: internal time
>>List reduced from 6168 to 20 due to restriction <20>
>>
>>ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>> 17.3987.3987.4017.401 {method 'next_event' of 
>> 'grpc._cython.cygrpc.SegregatedCall' objects}
>>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/grpc-io/Z6EBY2LzaGk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/f5df8252-554a-4363-aa35-8f0209451286n%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/01d51541-26f1-4ced-8379-4b6c5c24611dn%40googlegroups.com.

Re: [grpc-io] Re: {method 'next_event' of 'grpc._cython.cygrpc.SegregatedCall' objects} taking >6secs on MacOS

[Adam Walters]

Hi Zach,Sorry if this is a stupid question but what all are you looking for this file to contain?On May 17, 2023, at 3:55 PM, 'Zach Reyes' via grpc.io  wrote:Can you please provide a full reproducible file, rather than a single file. That we the team can benchmark.On Tuesday, May 16, 2023 at 1:55:11 PM UTC-4 Adam Walters wrote:Hello,Recently my program started running extremely slow and upon further investigation found that this '{method 'next_event' of 'grpc._cython.cygrpc.SegregatedCall' objects}' was taking over 5 seconds per call.I am using all of the latest versions grpc and google-ads packages.Below is an example of the code that is running and the results from a cProfile run:from google.ads.googleads.client import GoogleAdsClientfrom google.ads.googleads.v13.services.services.google_ads_service import pagersimport logginglogging.basicConfig(level=logging.INFO, format='[%(asctime)s - %(levelname)s] %(message).5000s')logging.getLogger('google.ads.googleads.client').setLevel(logging.INFO)client = GoogleAdsClient.load_from_storage("google-ads.yaml")google_ads_service = client.get_service("GoogleAdsService", version='v13')class GoogleQuery:"""A class to query Google Ads APIAttributes:client: An initialized GoogleAdsClient instance.mcc_id: The Google Ads MCC IDsearch_accounts_query: A query to return all search accountsdisplay_accounts_query: A query to return all display accountsMethods:get_existing_search_accounts: Returns a dictionary of existing search accountsget_existing_display_accounts: Returns a dictionary of existing display accountsrun_gaql_query: Runs a GAQL query and returns a Pager object"""def __init__(self):self.client = clientself.mcc_id = "XX"self.search_accounts_query = """SELECTcustomer_client.id,customer_client.resource_name,customer_client.descriptive_name,customer_client.manager,customer_client.applied_labelsFROM customer_clientWHEREcustomer_client.manager = false AND customer_client.id IS NOT NULL AND customer_client.descriptive_name LIKE '%Search%'AND customer.status = 'ENABLED'"""@staticmethoddef run_gaql_query(query: str, customer_id) -> pagers.SearchPager:"""runs GAQL query through Google Ads APIArgs:customer_id: customer ID being queriedquery: the actual GAQL query being ranReturns:Returns a pagers.SearchPager response of the raw data"""return google_ads_service.search(customer_id=customer_id,query=query)def get_existing_search_accounts(self) -> dict:"""runs GAQL query through Google Ads APIReturns:Returns a dict of {internal_id, account_name}"""response = self.run_gaql_query(self.search_accounts_query, self.mcc_id)return {row.customer_client.descriptive_name[-8:]: row.customer_client.descriptive_name for row in response}gaql = GoogleQuery()gaql.get_existing_search_accounts()# cProfile Results from above code

Tue May 16 13:31:28 2023    output_test.pstats         991213 function calls (973122 primitive calls) in 10.099 seconds   Ordered by: internal time   List reduced from 6168 to 20 due to restriction <20>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)        1    7.398    7.398    7.401    7.401 {method 'next_event' of 'grpc._cython.cygrpc.SegregatedCall' objects}



-- 
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/Z6EBY2LzaGk/unsubscribe.
To unsubscribe from this group and all its topics, 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/f5df8252-554a-4363-aa35-8f0209451286n%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/72663815-1BE2-40D8-BF20-353DD997FC98%40digible.com.

[grpc-io] Re: Talk gRPC meetup

['Larry Safran' via grpc.io]

Hi Rajiv,
  I am the right contact for this.  We're currently in the process of 
revamping the community meetups (which is why there has been a short break).
I really appreciate you offering to present and will get in touch with you 
directly  once we are ready.

Thanks,
  Larry

On Friday, May 5, 2023 at 2:45:33 PM UTC-7 Rajiv Singh wrote:

> Hello,
>
> I am interested in presenting a demo or sharing slides on the background 
> architecture of gRPC during the monthly gRPC meetups. My presentation will 
> focus on "Exploring the Power of gRPC-Gateway for Writing REST Services." 
> Could you please let me know whom I should contact to proceed with this 
> request?
>
> Thank you.
>
> *Regards,*
>
> *Rajiv Ranjan Singh*
>
> *Portfolio ** | **GitHub 
> ** | **LinkedIn 
> ** | **Twitter 
> *
>

-- 
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/0058293a-a6af-463c-8661-d4221933a794n%40googlegroups.com.

[grpc-io] Re: Calling SendAndClose stream does not result io.EOF error

[torpido]

I just realized that SendAndClose should not send EOF but simply indicate 
that the stream should be closed.
What I'm trying to achieve is for the gRPC server to close the streamhim 
self instead of waiting for the client to send EOF.
Can this be done from the gRPC server side? 

ב-יום רביעי, 17 במאי 2023 בשעה 22:57:01 UTC+3, Zach Reyes כתב/ה:

> Can you provide both the client and server code snippet (preferably 
> reproducible), so we can run and see what's going on here.
>
> On Wednesday, May 17, 2023 at 8:12:42 AM UTC-4 torpido wrote:
>
>> hi,
>>
>> Does anyone have any idea why when I call SendAndClose from the server 
>> stream I don't get an io.EOF error but instead the error is nil, so my 
>> stream is never closed?
>>
>

-- 
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/a5d08ec6-00bb-46a6-bb66-21d1d1d64e90n%40googlegroups.com.

[grpc-io] Re: Calling SendAndClose stream does not result io.EOF error

['Zach Reyes' via grpc.io]

Can you provide both the client and server code snippet (preferably 
reproducible), so we can run and see what's going on here.

On Wednesday, May 17, 2023 at 8:12:42 AM UTC-4 torpido wrote:

> hi,
>
> Does anyone have any idea why when I call SendAndClose from the server 
> stream I don't get an io.EOF error but instead the error is nil, so my 
> stream is never closed?
>

-- 
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/db2db5a9-780b-4013-9347-3d7ab6a13d9en%40googlegroups.com.

[grpc-io] Re: {method 'next_event' of 'grpc._cython.cygrpc.SegregatedCall' objects} taking >6secs on MacOS

['Zach Reyes' via grpc.io]

Can you please provide a full reproducible file, rather than a single file. 
That we the team can benchmark.

On Tuesday, May 16, 2023 at 1:55:11 PM UTC-4 Adam Walters wrote:

> Hello,
>
> Recently my program started running extremely slow and upon further 
> investigation found that this '{method 'next_event' of 
> 'grpc._cython.cygrpc.SegregatedCall' objects}' was taking over 5 seconds 
> per call.
>
> I am using all of the latest versions grpc and google-ads packages.
>
> Below is an example of the code that is running and the results from a 
> cProfile run:
> from google.ads.googleads.client import GoogleAdsClient
> from google.ads.googleads.v13.services.services.google_ads_service import 
> pagers
> import logging
>
> logging.basicConfig(level=logging.INFO, format='[%(asctime)s - 
> %(levelname)s] %(message).5000s')
> logging.getLogger('google.ads.googleads.client').setLevel(logging.INFO)
>
> client = GoogleAdsClient.load_from_storage("google-ads.yaml")
> google_ads_service = client.get_service("GoogleAdsService", version='v13')
>
> class GoogleQuery:
> """A class to query Google Ads API
>
> Attributes:
> client: An initialized GoogleAdsClient instance.
> mcc_id: The Google Ads MCC ID
> search_accounts_query: A query to return all search accounts
> display_accounts_query: A query to return all display accounts
>
> Methods:
> get_existing_search_accounts: Returns a dictionary of existing search 
> accounts
> get_existing_display_accounts: Returns a dictionary of existing display 
> accounts
> run_gaql_query: Runs a GAQL query and returns a Pager object
> """
>
> def __init__(self):
> self.client = client
> self.mcc_id = "XX"
> self.search_accounts_query = """SELECT
> customer_client.id,
> customer_client.resource_name,
> customer_client.descriptive_name,
> customer_client.manager,
> customer_client.applied_labels
> FROM 
> customer_client
> WHERE
> customer_client.manager = false 
> AND customer_client.id IS NOT NULL 
> AND customer_client.descriptive_name LIKE '%Search%'
> AND customer.status = 'ENABLED'"""
>
> @staticmethod
> def run_gaql_query(query: str, customer_id) -> pagers.SearchPager:
> """runs GAQL query through Google Ads API
> Args:
> customer_id: customer ID being queried
> query: the actual GAQL query being ran
> Returns:
> Returns a pagers.SearchPager response of the raw data
> """
> return google_ads_service.search(
> customer_id=customer_id,
> query=query
> )
>
> def get_existing_search_accounts(self) -> dict:
> """runs GAQL query through Google Ads API
>
> Returns:
> Returns a dict of {internal_id, account_name}
> """
> response = self.run_gaql_query(self.search_accounts_query, self.mcc_id)
> return {row.customer_client.descriptive_name[-8:]: 
> row.customer_client.descriptive_name for row in response}
>
> gaql = GoogleQuery()
> gaql.get_existing_search_accounts()
>
> # cProfile Results from above code Tue May 16 13:31:28 2023   
>  output_test.pstats
>
>  991213 function calls (973122 primitive calls) in 10.099 seconds
>
>Ordered by: internal time
>List reduced from 6168 to 20 due to restriction <20>
>
>ncalls  tottime  percall  cumtime  percall filename:lineno(function)
> 17.3987.3987.4017.401 {method 'next_event' of 
> 'grpc._cython.cygrpc.SegregatedCall' objects}
>

-- 
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/f5df8252-554a-4363-aa35-8f0209451286n%40googlegroups.com.

[grpc-io] Re: GRPC Serializer does call at the time of GRPC request calling why

['Zach Reyes' via grpc.io]

What language are you using? Can you please provide more information? I 
don't know what pdb is referring to.

On Monday, May 15, 2023 at 7:45:10 AM UTC-4 Joseph Anjilimoottil wrote:

> Hi Guys,
> I am working on the project and i want to do  nested serializer  and in 
> that i want  to do data filtering based on the request while API calling 
> but the pdb does not hit but while saving it hit the pdb  in the serialize 
> why.
>
> can you please give me answer on these questions
>
>

-- 
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/3e09bf84-cb17-4c6b-9931-2921131e70c2n%40googlegroups.com.

[grpc-io] Re: gRPC client side request throttling

['Zach Reyes' via grpc.io]

Can both of y'all please provide more context. I.e. a client and server 
side code snippet, something where the team can reproduce? Thanks.

On Friday, May 12, 2023 at 3:55:18 AM UTC-4 Vamsi Deepak wrote:

>
> https://stackoverflow.com/questions/76219206/grpc-module-throwing-error-with-electron-js
> Facing above issue . any one has any idea  ??
>
> On Thursday, May 11, 2023 at 8:35:44 PM UTC+5:30 Bhuvi Viji wrote:
>
>> Hi,
>>
>> Currently  we are doing some performance testing with our gRPC based 
>> server and client apps and below are the Observations with the test results 
>> and Need feedback on this.
>>
>> 1.Even if the upstream gRPC service is up and running, client gets 
>> "Unreachable error" at times - what is the exact reason. We have configured 
>> retries to resolve the issue. But would like to understand what is 
>> happening behind it.
>>
>> 2. We configured have configured semaphore object to throttle request in 
>> client side even with Semaphore count of 10 , still seeing retries, its 
>> same as without having the semaphore object so would like to know the 
>> client side connection queueing feature where we can limit the connections 
>> on the channel instead of using a separate variables.
>>
>>

-- 
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/c18aaa0f-5b62-4405-ace7-b1e1fa8dca62n%40googlegroups.com.

[grpc-io] Re: Set seems to not set the field value

['Zach Reyes' via grpc.io]

Can you please post a longer code snippet (i.e. the full client and server 
side code snippet) so we can tell what's going on.

On Thursday, May 11, 2023 at 2:57:27 AM UTC-4 Tobias Krueger wrote:

> Sorry - it is hard to tell what is wrong.
> As a side effect (calling a const function) changes the behavior, you 
> should search of some other generic problem (race-conditions, 
> wrong/incompatible libraries, dangling pointers, whatever in C++ can go 
> wrong).
>
>
> On Wednesday, May 10, 2023 at 5:59:36 PM UTC+2 Matteo Stefanini wrote:
>
>>
>> > The generated method "counter()" should be const (at least with new 
>> protoc compilers), therefor it cannot have any impact if you call it or not.
>>
>> You are right, this is the implementation of the autogenerated code:
>>
>> inline ::uint32_t Response::counter() const {
>> // @@protoc_insertion_point(field_get:Response.counter)
>> return _internal_counter();
>> }
>>
>> Where can I check where the problem is? 
>>
>> I don't have a clue due to the very small part of the code being pretty 
>> straightforward
>>
>> On Wednesday, 10 May 2023 at 17:05:28 UTC+2 Tobias Krueger wrote:
>>
>>> >  Am I doing something wrong?
>>>
>>> IMHO there must be something different.
>>>
>>> The generated method "counter()" should be const (at least with new 
>>> protoc compilers), therefor it cannot have any impact if you call it or not.
>>>
>>>
>>> On Wednesday, May 10, 2023 at 4:58:33 PM UTC+2 Matteo Stefanini wrote:
>>>
 Hi everyone,

 I'm trying to send an integer back to the client but no data are sent. 
 The only solution found is to call 'response->counter()' before sending 
 it

 message Response 
 {
 string message = 1;
 uint32 time_ms = 2;
 bool is_over = 3;
 uint32 counter = 4;
 }


 Status Step(ServerContext* context, const service::Request* request, 
 service::Response* response) override 
 {
 response->set_message( "step_success" );
 response->set_is_over( true );
 response->set_counter( 10 );
 response->counter();

 return Status::OK;
 }

 Am I doing something wrong? 

>>>

-- 
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/5d15025b-5baa-4df5-a46d-6a09727be079n%40googlegroups.com.

Re: [grpc-io] Custom channels

['Zach Reyes' via grpc.io]

We use the standard library net.Conn, which you can think of as a TCP 
connection.

On Wednesday, May 17, 2023 at 3:33:39 PM UTC-4 Zach Reyes wrote:

> At least for gRPC GoLang, Custom Transports are not currently supported.
>
> On Wednesday, May 10, 2023 at 10:44:03 PM UTC-4 Saigut wrote:
>
>> Hi, how to custom the endpoint, is there any document or example?  I want 
>> to manage the sending and receiving of bytes myself.
>> Thank you.
>> 在2015年10月7日星期三 UTC+8 05:41:26 写道：
>>
>>> Well, so there's really 3 layers in gRPC.
>>>
>>> 1. There's what we call the endpoint, which in our case is currently 
>>> TCP. The role of an endpoint is to send and receive bytes, and signal the 
>>> upper layers of events, such as connection lost, or there's bytes ready to 
>>> read. The API for that one is really simple, and I think we've reached the 
>>> point where it's mature enough it's not going to change. So writing another 
>>> endpoint should prove fairly stable over time. It's not a guarantee 
>>> however, and we kind of reserve the right to break that API in the future. 
>>> We don't have any plan to expose it above the C core. Meaning that we've 
>>> made it so that one could provide a plugin to gRPC to add another endpoint. 
>>> Now that plugin on your side could be written in any language you want, as 
>>> long as it provides a C interface for the core to use. We might move this 
>>> to the official, immutable API some time.
>>>
>>> 2. Then there's the transport, which right now is HTTP2. It's used to 
>>> transport the RPC payloads, and also to transport metadata. These metadata 
>>> are encoded using HTTP headers. Here's the actual details of that: 
>>> https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md - if you 
>>> wanted to change the transport, you'd also need to make sure the metadata 
>>> are properly encoded and transmitted. Which is why I was suggesting NOT 
>>> changing that layer, but rather the endpoint one, so you only have to 
>>> implement the first layer that is pumping bytes from one side to another. 
>>> You wouldn't have to worry about the metadata.
>>>
>>> 3. Finally there's the actual RPC payload. gRPC technically doesn't care 
>>> about what's in that payload. Our examples and some upper layers of the 
>>> code are using protobuf, but the C++ layer should let you use any kind of 
>>> payload you want instead. The code should already be there to allow for 
>>> that. More specifically, from my memory, there should be a generic 
>>> template, and a protobuf-specific one, in the C++ headers. So, JSON, 
>>> flatbuffers, or XML, what you want, just specialize the template.
>>>
>>> On Tue, Oct 6, 2015 at 1:53 PM, Pavol Ostertag  
>>> wrote:
>>>
 Thank you for comprehensive answer. Comprehensive answers produce more 
 questions, so here are mine :)

  

 1. Is it planned to make that plumbing in C++ official in the future? 
 (so that the plumbing does not need to be rewritten with every GRPC update)

 2. If I am getting you right, you suggest tunneling HTTP2 through LPC 
 or DNS. Interesting idea

 3. Would it be similarly easy to replace serializer (or marshaller) 
 with another one serializing into XML? (in our company the transfer to 
 GRPC 
 would be far easier if the change can be done in two-steps - clients first 
 and backend later, when "GRPC client" deployments reach some level)

  

 *From:* Nicolas Noble [mailto:pixel...@gmail.com] 
 *Sent:* Tuesday, October 06, 2015 10:17 PM
 *To:* pavol.o...@gmail.com
 *Cc:* grpc.io 
 *Subject:* Re: [grpc-io] Custom channels

  

 The way it works is lower level than that. What you want is a transport 
 implementation, not a channel implementation. Transports aren't exposed to 
 the C++ interface, so you'll have to add them to the C core. This is 
 located in https://github.com/grpc/grpc/tree/master/src/core/transport 
 - and if you want a protocol that isn't HTTP2, this is where you need to 
 start poking at. More specifically, look at 
 https://github.com/grpc/grpc/blob/master/src/core/transport/transport_impl.h
  
 and this is where you'll see the interface used by the rest of the code to 
 "talk protocol".

  

 There's probably some plumbing needed to properly bubble up the 
 transport switch to the C++ API however.

  

  

 But given what you are talking about, it seems you rather want an 
 endpoint instead. This might prove easier. It'll still use HTTP2 as an 
 encapsulating protocol, but not on top of a TCP connection. What I am 
 saying is that I am arguing that HTTP2 and "LPC" are two complementary 
 things, not interchangeable. But TCP and LPC are.

  

 This is the code that is located there instead: 
 https://github.com/grpc/grpc/tree/master/src/core/iomgr - there is a 
 Windows and a Linux / posix 

Re: [grpc-io] Custom channels

['Zach Reyes' via grpc.io]

At least for gRPC GoLang, Custom Transports are not currently supported.

On Wednesday, May 10, 2023 at 10:44:03 PM UTC-4 Saigut wrote:

> Hi, how to custom the endpoint, is there any document or example?  I want 
> to manage the sending and receiving of bytes myself.
> Thank you.
> 在2015年10月7日星期三 UTC+8 05:41:26 写道：
>
>> Well, so there's really 3 layers in gRPC.
>>
>> 1. There's what we call the endpoint, which in our case is currently TCP. 
>> The role of an endpoint is to send and receive bytes, and signal the upper 
>> layers of events, such as connection lost, or there's bytes ready to read. 
>> The API for that one is really simple, and I think we've reached the point 
>> where it's mature enough it's not going to change. So writing another 
>> endpoint should prove fairly stable over time. It's not a guarantee 
>> however, and we kind of reserve the right to break that API in the future. 
>> We don't have any plan to expose it above the C core. Meaning that we've 
>> made it so that one could provide a plugin to gRPC to add another endpoint. 
>> Now that plugin on your side could be written in any language you want, as 
>> long as it provides a C interface for the core to use. We might move this 
>> to the official, immutable API some time.
>>
>> 2. Then there's the transport, which right now is HTTP2. It's used to 
>> transport the RPC payloads, and also to transport metadata. These metadata 
>> are encoded using HTTP headers. Here's the actual details of that: 
>> https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md - if you 
>> wanted to change the transport, you'd also need to make sure the metadata 
>> are properly encoded and transmitted. Which is why I was suggesting NOT 
>> changing that layer, but rather the endpoint one, so you only have to 
>> implement the first layer that is pumping bytes from one side to another. 
>> You wouldn't have to worry about the metadata.
>>
>> 3. Finally there's the actual RPC payload. gRPC technically doesn't care 
>> about what's in that payload. Our examples and some upper layers of the 
>> code are using protobuf, but the C++ layer should let you use any kind of 
>> payload you want instead. The code should already be there to allow for 
>> that. More specifically, from my memory, there should be a generic 
>> template, and a protobuf-specific one, in the C++ headers. So, JSON, 
>> flatbuffers, or XML, what you want, just specialize the template.
>>
>> On Tue, Oct 6, 2015 at 1:53 PM, Pavol Ostertag  
>> wrote:
>>
>>> Thank you for comprehensive answer. Comprehensive answers produce more 
>>> questions, so here are mine :)
>>>
>>>  
>>>
>>> 1. Is it planned to make that plumbing in C++ official in the future? 
>>> (so that the plumbing does not need to be rewritten with every GRPC update)
>>>
>>> 2. If I am getting you right, you suggest tunneling HTTP2 through LPC or 
>>> DNS. Interesting idea
>>>
>>> 3. Would it be similarly easy to replace serializer (or marshaller) with 
>>> another one serializing into XML? (in our company the transfer to GRPC 
>>> would be far easier if the change can be done in two-steps - clients first 
>>> and backend later, when "GRPC client" deployments reach some level)
>>>
>>>  
>>>
>>> *From:* Nicolas Noble [mailto:pixel...@gmail.com] 
>>> *Sent:* Tuesday, October 06, 2015 10:17 PM
>>> *To:* pavol.o...@gmail.com
>>> *Cc:* grpc.io 
>>> *Subject:* Re: [grpc-io] Custom channels
>>>
>>>  
>>>
>>> The way it works is lower level than that. What you want is a transport 
>>> implementation, not a channel implementation. Transports aren't exposed to 
>>> the C++ interface, so you'll have to add them to the C core. This is 
>>> located in https://github.com/grpc/grpc/tree/master/src/core/transport 
>>> - and if you want a protocol that isn't HTTP2, this is where you need to 
>>> start poking at. More specifically, look at 
>>> https://github.com/grpc/grpc/blob/master/src/core/transport/transport_impl.h
>>>  
>>> and this is where you'll see the interface used by the rest of the code to 
>>> "talk protocol".
>>>
>>>  
>>>
>>> There's probably some plumbing needed to properly bubble up the 
>>> transport switch to the C++ API however.
>>>
>>>  
>>>
>>>  
>>>
>>> But given what you are talking about, it seems you rather want an 
>>> endpoint instead. This might prove easier. It'll still use HTTP2 as an 
>>> encapsulating protocol, but not on top of a TCP connection. What I am 
>>> saying is that I am arguing that HTTP2 and "LPC" are two complementary 
>>> things, not interchangeable. But TCP and LPC are.
>>>
>>>  
>>>
>>> This is the code that is located there instead: 
>>> https://github.com/grpc/grpc/tree/master/src/core/iomgr - there is a 
>>> Windows and a Linux / posix implementation of TCP endpoints. If you add 
>>> another endpoint, the core will use your code instead, and the plumbing to 
>>> change it at runtime should already be there and easier to use.
>>>
>>>  
>>>
>>> On Tue, Oct 6, 2015 at 7:59 AM,  wrote:
>>>
>>>

Re: [grpc-io] Re: USB transport

[Frédéric Martinsons]

Hello Tom,

Two years ago, I managed to get an USB channel based on grpc 1.35 , you can
see this work on my personal grpc fork:
https://github.com/fmartinsons/grpc/tree/grpc-usb-1.35.0

Sadly, from what I remember, I didn't manage to make it work on my target
machine (I got spurious USB disconnections).
I didn't have the time to continue and I don't plan to work on it again but
feel free to get the code and try it by yourself.

I'd appreciate it greatly if you manage to have a working code and publish
it.

Have a nice day.

On Wed, 10 May 2023 at 05:26, Tom Stoffer  wrote:

> Hi Frédéric
>
> I would be interested in seeing this MR, we are looking at implementing
> something like this. Did your code get used in production?
>
> Tom
>
> On Thursday, February 25, 2021 at 12:07:01 AM UTC+13 Frédéric Martinsons
> wrote:
>
>>
>> Anybody there ?
>>
>> I think I'll made the above mentionned merge request and we will see if
>> it is accepted or not.
>> On Saturday, 13 February 2021 at 11:49:05 UTC+1 Frédéric Martinsons wrote:
>>
>>>
>>> There is another thread talking about USB support:
>>> https://groups.google.com/g/grpc-io/c/MZCVUShRMkM/m/y3T_fs8iAQAJ but I
>>> cannot answer there since my messages are automatically deleted (don't know
>>> why)
>>>
>>>
>>> On Saturday, 13 February 2021 at 09:55:42 UTC+1 Frédéric Martinsons
>>> wrote:
>>>
 Hello all,

 Some years ago we had the exact same use case where we have an android
 application which drive an embedded devices (in USB Accessory Mode). The
 only way to communicate with this device is through USB channel and we
 wanted to use gRPC.
 So we develop the USB transport channel in gRPC bask in 2018 (based on
 gRPC v1.13.0).
 The guy from our teams that made these patches had now leaved but I'll
 be glad to submit a patch series if the USB support is still foreseen to be
 support but I may not be able to answer all the questions about tricks that
 came in this code.

 Do you want to receive a merge request ?

 Thanks for the good works gRPC guru.

 On Thursday, 8 February 2018 at 17:18:21 UTC+1 robert...@gmail.com
 wrote:

> Mark, as Abhishek mentioned, it is quite useful in cases where a
> target device (usually embedded) has no networking. Thanks Vijay, I'll 
> have
> a look at your suggestions.
>
> Regards
> /Robert
>
> 2018-02-07 22:31 GMT+01:00 'Vijay Pai' via grpc.io <
> grp...@googlegroups.com>:
>
>> As Mark mentioned, it's not on our roadmap, but if you wanted to put
>> one together, I can suggest
>> https://github.com/grpc/grpc/blob/master/doc/core/transport_explainer.md
>> for an idea of what transports need to do. If the goal is a simple
>> message-oriented transport without reference to complex flow control, I 
>> can
>> suggest using the in-process transport as a model for how to build a
>> transport, as it's only a few hundred lines of code and implements the
>> transport ops required to actually have working RPCs for its context; 
>> this
>> might make a lot of sense if your controller is memory-mapped.
>> Alternatively, if your controller is mapped as a file, a path forward 
>> might
>> be to make a new endpoint akin to the UDS endpoint. This would mean that
>> you'd be speaking HTTP/2 over your HID, but again it may be a fairly 
>> simple
>> integration.
>>
>> Good luck!
>>
>> - Vijay
>>
>> On Friday, February 2, 2018 at 8:51:23 PM UTC-8, Robert Bielik wrote:
>>>
>>> Hi all,
>>>
>>> Has there been any work on using USB HID as a gRPC transport ?
>>>
>>> Regards
>>> /Robert
>>>
>>> --
>> You received this message because you are subscribed to a topic in
>> the Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/grpc-io/rCOTPM65A7U/unsubscribe.
>>
> To unsubscribe from this group and all its topics, 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/e25acae8-c505-47f6-a108-23d4d5d61a83%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 view this discussion on the web visit
> 

[grpc-io] Proxyless gRPC services in Istio mesh

[Wesley Hartford]

I'm using the xDS support in grpc-java to build a sample project with 
proxyless client and server in Kotlin which participate in an Istio service 
mesh. My project is available here: 
https://github.com/wfhartford/kotlin-grpc-xds

I got everything working without too much trouble, but I'm a little 
concerned that things might not be working as intended.

What's working correctly:

   - Client and server can communicate,
   - Client requests are round-robin load-balanced across multiple service 
   instances.

What doesn't seem right:

   - A server interceptor reports that ServerCall.getSecurityLevel() 
   returns NONE,
   - When I configure Istio to enforce STRICT mTLS via a namespace wide 
   PeerAuthentication resource, the client's connection to the server fails 
   with: io.grpc.StatusException: UNAVAILABLE: Connection timeout for 
   priority outbound|8443||server.kotlin-grpc-xds.svc.cluster.local[child1]

Is this the expected behavior, or have I missed something?

Thanks for any insight you might have.

Wesley

-- 
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/a516a4db-38e9-4e10-94f2-11187f5ec49bn%40googlegroups.com.

[grpc-io] Calling SendAndClose stream does not result io.EOF error

[torpido]

hi,

Does anyone have any idea why when I call SendAndClose from the server 
stream I don't get an io.EOF error but instead the error is nil, so my 
stream is never closed?

-- 
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/11b92696-332e-40a6-a671-301a15f9a4b5n%40googlegroups.com.