[grpc-io] Re: Can't compile gRPC 1.57.0
I'm not sure exactly how, but my suspicion is that you are somehow picking up an old `ares.h` on your include path. For what it's worth, we upgraded the c-ares dependency to 1.19.1 starting on the 1.56 release (see https://github.com/grpc/grpc/pull/33411). At that version, note that `src/lib/ares__addrinfo2hostent.c` includes `ares.h` and `ares.h` defines `struct ares_addrinfo`. gRPC 1.43 built with the older 1.15 version of c-ares, which did not introduce yet `struct ares_addrinfo`. So perhaps the version of ares.h your picking up is compatible with the 1.15 c-ares build but not the 1.19.1 build. On Friday, August 25, 2023 at 3:21:32 PM UTC-7 John Ousterhout wrote: > I have been working with gRPC 1.43.0 and tried today to upgrade to 1.57.0. > However, when I try to build for debug, the cares submodule doesn't compile > because the types "struct ares_addrinfo", "struct addrinfo_node", and > "struct addrinfo_cname" are not defined. Here are a couple of sample error > messages: > > /ares__addrinfo2hostent.c:68:32: error: invalid use of undefined type > 'const struct ares_addrinfo' >68 | if (family == AF_UNSPEC && ai->nodes) > |^~ > /ouster/grpc/third_party/cares/cares/src/lib/ares__addrinfo2hostent.c:74:14: > error: invalid use of undefined type 'struct ares_addrinfo_node' >74 | if(next->ai_family == family) > | ^~ > | ^~ > /ouster/grpc/third_party/cares/cares/src/lib/ares__addrinfo2hostent.c:227:30: > error: invalid use of undefined type 'struct ares_addrinfo_cname' > 227 | next_cname = next_cname->next; > | ^~ > > Has anyone else seen these errors? Any suggestions on how to get past this > problem? Thanks in advance for any help you can provide. > > -John- > -- 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/d377c072-d527-42a6-8f7f-ad67d2c91581n%40googlegroups.com.
[grpc-io] Can't compile gRPC 1.57.0
I have been working with gRPC 1.43.0 and tried today to upgrade to 1.57.0. However, when I try to build for debug, the cares submodule doesn't compile because the types "struct ares_addrinfo", "struct addrinfo_node", and "struct addrinfo_cname" are not defined. Here are a couple of sample error messages: /ares__addrinfo2hostent.c:68:32: error: invalid use of undefined type 'const struct ares_addrinfo' 68 | if (family == AF_UNSPEC && ai->nodes) |^~ /ouster/grpc/third_party/cares/cares/src/lib/ares__addrinfo2hostent.c:74:14: error: invalid use of undefined type 'struct ares_addrinfo_node' 74 | if(next->ai_family == family) | ^~ | ^~ /ouster/grpc/third_party/cares/cares/src/lib/ares__addrinfo2hostent.c:227:30: error: invalid use of undefined type 'struct ares_addrinfo_cname' 227 | next_cname = next_cname->next; | ^~ Has anyone else seen these errors? Any suggestions on how to get past this problem? Thanks in advance for any help you can provide. -John- -- 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/e4167c63-b8fe-4c97-bf00-19122e86f8bbn%40googlegroups.com.
[grpc-io] gRFC L106: L106: Node Heath Check Library 2.0
https://github.com/grpc/proposal/pull/391 is a gRFC for defining a new API for the Node gRPC health check library. Feedback welcome. -- 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/CAPK2-4fQGn797DGunJsitb3PFFOVcgiXogoCNKE5dw6%2Bj%3DvXpg%40mail.gmail.com. smime.p7s Description: S/MIME Cryptographic Signature
Re: [grpc-io] Re: After the channel is created, it takes 1000+ms to transition from IDEL state to CONNECTING state.How can i reduce the time required to change state?
Oh, I didn't realize your grpc java version was so old. Good to know your issue is resolved. On Fri, Aug 25, 2023 at 1:23 AM '邹会江' via grpc.io wrote: > Thanks！ > I upgrade the grpc-java version from 1.3.3 to 1.51.0, and the IDLE time is > reduced from 1000ms to 300ms. > > 在2023年8月25日星期五 UTC+8 13:05:56 写道： > >> Instead of modifying and using the jre/lib logging.properties file can >> you try using one for your application alone as described in my previous >> message (use Java property java.util.logging.config.file and so on)? >> >> On Wednesday, August 23, 2023 at 7:49:39 PM UTC-7 邹会江 wrote: >> >>> 1. I modified the logging.properties file under jre/lib: >>> handlers=java.util.logging.ConsoleHandler >>> io.grpc.ChannelLogger.level=FINEST >>> io.grpc.level=FINEST >>> io.netty.level=FINEST >>> java.util.logging.ConsoleHandler.level=ALL >>> >>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter >>> but grpc doesn't have any log output to the console. >>> >>> 在2023年8月24日星期四 UTC+8 02:32:08 写道： >>> On Wed, Aug 23, 2023 at 1:37 AM '邹会江' via grpc.io < grp...@googlegroups.com> wrote: > Sanjay Pujare： > Thank you for your reply! > 1. How do i enable trace logging? > It uses java util logging so to enable using JAVA_OPTS: export JAVA_OPTS="-Djava.util.logging.config.file=/logging.properties" And in /logging.properties have this: handlers=java.util.logging.ConsoleHandler io.grpc.ChannelLogger.level=FINEST io.grpc.level=FINEST io.netty.level=FINEST java.util.logging.ConsoleHandler.level=ALL java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter Or you can tweak it to your liking. > 2. DNS resolution,TLS hanshake and TCP connection.In this case,the > state of channel should be CONNECTING? Yes. > Therefore,the TCP connectio only affects the CONNECTING time, but not > the IDLE time. > Not sure I understand this comment/question. But when it is trying to establish the TCP connection, yes the status is CONNECTING > > 在2023年8月23日星期三 UTC+8 14:23:02 写道： > >> Most of the time is spent in IDLE -> CONNECTING transition. From this >> doc >> https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md >> which says for CONNECTING >> >> CONNECTING: The channel is trying to establish a connection and is >> waiting to make progress on one of the steps involved in name resolution, >> TCP connection establishment or TLS handshake. This may be used as the >> initial state for channels upon creation. >> >> DNS resolution and TLS handshake (since you are not calling >> usePlaintext() on the builder) are possible culprits. Even TCP connection >> establishment is a possibility depending on where the target is. If you >> enable trace logging you might be able to figure out. >> >> On Tue, Aug 22, 2023 at 10:08 PM '邹会江' via grpc.io < >> grp...@googlegroups.com> wrote: >> >>> Thank you for your reply! >>> 1. The first time: >>> The transition from idle state to connecting takes: 3377 ms, >>> The transition from idle state to ready takes: 3679 ms >>> 2. The second time: >>> The transition from idle state to connecting takes: 1643 ms, >>> The transition from idle state to ready takes: 1797 ms >>> 3.The third time: >>> The transition from idle state to connecting takes: 1019 ms, >>> The transition from idle state to ready takes: 1049 ms >>> 4. What is my enviroment? >>> MacBook Pro (16-inch, 2019) >>> 2.6 GHz 6 core Intel Core i7 >>> 16 GB 2667 MHz DDR4 >>> >>> 在2023年8月23日星期三 UTC+8 04:31:28 写道： >>> Another question is whether this is the same the second time you create a channel. The first time, the JVM may be taking time doing class loading. On Tue, Aug 22, 2023 at 8:41 AM 'Yuri Golobokov' via grpc.io < grp...@googlegroups.com> wrote: > Hello, > What is the round-trip time? How much time does DNS resolution > take? > > On Tuesday, August 22, 2023 at 12:02:21 AM UTC-7 邹会江 wrote: > >> ### JAVA Code >> >> ``` >> channel = >> ManagedChannelBuilder.forTarget(param.getTarget()).build(); >> long channelStart = System.currentTimeMillis(); >> asyncStub = ASRRouteGrpc.newStub(channel); >> asrResponseStreamObserver = new >> ASRResponseStreamObserver(speechTranscriberListener); >> requestObserver = >> asyncStub.route(asrResponseStreamObserver); >> RouteRequest requestConf = newRequestHead(param); >> traceId = requestConf.getAsrConfig().getTraceId();
[grpc-io] Re: Posting example code for asynchronous streaming implementation [subscription based services]
Thanks for example, but I have one doubt in Client code:
call->response_reader = stub_->AsyncSayHello(>context, request, _,
(void *)call);
What if we receive response in bool HandleResponse(bool responseStatus)
before call->response_reader is assigned. Isn't it potential racing
condition? We could have context switch after RPC is fully initialized, but
before assignment happens.
On Tuesday, December 13, 2022 at 10:34:11 a.m. UTC-5 Tom Mclean wrote:
>
> Amazing.
>
> Thank you so much.
> On Thursday, April 27, 2017 at 7:10:56 AM UTC+1 kuldeepm...@gmail.com
> wrote:
>
>> While implementing asynchronous streaming grpc, there are no straight
>> forward examples that can be used, it was hard time for me to implement it.
>> Now that I have implemented the hello world version of async stream
>> version, I thought I will share.
>>
>> In this example, client will request for stream of replies by initiating
>> asynchronous RPC and the server will respond with 5 replies, after server
>> is done with 5 replies it will close the RPC by calling finish and then
>> client will close the RPC.
>>
>> Hope it will be helpful.
>>
>> Thanks
>> Kuldeep
>>
>> *Protocol Buffer:*
>> // The greeting service definition.
>> service Greeter {
>> // Sends a greeting
>> rpc SayHello (HelloRequest) returns (stream HelloReply) {}
>> }
>>
>> // The request message containing the user's name.
>> message HelloRequest {
>> string name = 1;
>> }
>>
>> // The response message containing the greetings
>> message HelloReply {
>> string message = 1;
>> }
>>
>> Server Code:
>> class ServerImpl final {
>> public:
>> ~ServerImpl() {
>> server_->Shutdown();
>> // Always shutdown the completion queue after the server.
>> cq_->Shutdown();
>> }
>>
>> // There is no shutdown handling in this code.
>> void Run() {
>> std::string server_address("0.0.0.0:50051");
>>
>> ServerBuilder builder;
>> // Listen on the given address without any authentication
>> mechanism.
>> builder.AddListeningPort(server_address,
>> grpc::InsecureServerCredentials());
>> // Register "service_" as the instance through which we'll
>> communicate with
>> // clients. In this case it corresponds to an *asynchronous*
>> service.
>> builder.RegisterService(_);
>> // Get hold of the completion queue used for the asynchronous
>> communication
>> // with the gRPC runtime.
>> cq_ = builder.AddCompletionQueue();
>> // Finally assemble the server.
>> server_ = builder.BuildAndStart();
>> std::cout << "Server listening on " << server_address <<
>> std::endl;
>>
>> // Proceed to the server's main loop.
>> HandleRpcs();
>> }
>>
>> private:
>> // Class encompasing the state and logic needed to serve a request.
>> class CallData {
>> public:
>> // Take in the "service" instance (in this case representing an
>> asynchronous
>> // server) and the completion queue "cq" used for asynchronous
>> communication
>> // with the gRPC runtime.
>> CallData(Greeter::AsyncService* service, ServerCompletionQueue*
>> cq)
>> : service_(service), cq_(cq), repliesSent_(0),
>> responder_(_), status_(CREATE) {
>> // Invoke the serving logic right away.
>> Proceed();
>> }
>>
>> void Proceed() {
>> if (status_ == CREATE) {
>> // Make this instance progress to the PROCESS state.
>> status_ = PROCESS;
>> std::cout << "Creating Call data for new client
>> connections: " << this << std::endl;
>> // As part of the initial CREATE state, we *request* that
>> the system
>> // start processing SayHello requests. In this request,
>> "this" acts are
>> // the tag uniquely identifying the request (so that
>> different CallData
>> // instances can serve different requests concurrently),
>> in this case
>> // the memory address of this CallData instance.
>> service_->RequestSayHello(_, _, _,
>> cq_, cq_,
>> (void*) this);
>> } else if (status_ == PROCESS) {
>> // Spawn a new CallData instance to serve new clients
>> while we process
>> // the one for this CallData. The instance will
>> deallocate itself as
>> // part of its FINISH state.
>> new CallData(service_, cq_);
>>
>> // The actual processing.
>> std::string prefix("Hello ");
>> reply_.set_message(prefix + request_.name() +
>> std::to_string(repliesSent_ + 1));
>> std::cout << "Sending reponse: " << this << " : " <<
>> reply_.message() << std::endl;
>> responder_.Write(reply_, this);
>>
Re: [grpc-io] Re: After the channel is created, it takes 1000+ms to transition from IDEL state to CONNECTING state.How can i reduce the time required to change state?
Thanks！
I upgrade the grpc-java version from 1.3.3 to 1.51.0, and the IDLE time is
reduced from 1000ms to 300ms.
在2023年8月25日星期五 UTC+8 13:05:56 写道：
> Instead of modifying and using the jre/lib logging.properties file can you
> try using one for your application alone as described in my previous
> message (use Java property java.util.logging.config.file and so on)?
>
> On Wednesday, August 23, 2023 at 7:49:39 PM UTC-7 邹会江 wrote:
>
>> 1. I modified the logging.properties file under jre/lib:
>> handlers=java.util.logging.ConsoleHandler
>> io.grpc.ChannelLogger.level=FINEST
>> io.grpc.level=FINEST
>> io.netty.level=FINEST
>> java.util.logging.ConsoleHandler.level=ALL
>>
>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>> but grpc doesn't have any log output to the console.
>>
>> 在2023年8月24日星期四 UTC+8 02:32:08 写道：
>>
>>> On Wed, Aug 23, 2023 at 1:37 AM '邹会江' via grpc.io <
>>> grp...@googlegroups.com> wrote:
>>>
Sanjay Pujare：
Thank you for your reply!
1. How do i enable trace logging?
>>>
>>> It uses java util logging so to enable using JAVA_OPTS:
>>>
>>> export JAVA_OPTS="-Djava.util.logging.config.file=/logging.properties"
>>>
>>> And in /logging.properties have this:
>>>
>>> handlers=java.util.logging.ConsoleHandler
>>> io.grpc.ChannelLogger.level=FINEST
>>> io.grpc.level=FINEST
>>> io.netty.level=FINEST
>>> java.util.logging.ConsoleHandler.level=ALL
>>>
>>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>>
>>> Or you can tweak it to your liking.
>>>
>>>
2. DNS resolution,TLS hanshake and TCP connection.In this case,the
state of channel should be CONNECTING?
>>>
>>>
>>> Yes.
>>>
>>>
Therefore,the TCP connectio only affects the CONNECTING time, but not
the IDLE time.
>>>
>>> Not sure I understand this comment/question. But when it is trying to
>>> establish the TCP connection, yes the status is CONNECTING
>>>
>>>
在2023年8月23日星期三 UTC+8 14:23:02 写道：
> Most of the time is spent in IDLE -> CONNECTING transition. From this
> doc
> https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
>
> which says for CONNECTING
>
> CONNECTING: The channel is trying to establish a connection and is
> waiting to make progress on one of the steps involved in name resolution,
> TCP connection establishment or TLS handshake. This may be used as the
> initial state for channels upon creation.
>
> DNS resolution and TLS handshake (since you are not calling
> usePlaintext() on the builder) are possible culprits. Even TCP connection
> establishment is a possibility depending on where the target is. If you
> enable trace logging you might be able to figure out.
>
> On Tue, Aug 22, 2023 at 10:08 PM '邹会江' via grpc.io <
> grp...@googlegroups.com> wrote:
>
>> Thank you for your reply!
>> 1. The first time:
>> The transition from idle state to connecting takes: 3377 ms,
>> The transition from idle state to ready takes: 3679 ms
>> 2. The second time:
>> The transition from idle state to connecting takes: 1643 ms,
>> The transition from idle state to ready takes: 1797 ms
>> 3.The third time:
>> The transition from idle state to connecting takes: 1019 ms,
>> The transition from idle state to ready takes: 1049 ms
>> 4. What is my enviroment?
>> MacBook Pro (16-inch, 2019)
>> 2.6 GHz 6 core Intel Core i7
>> 16 GB 2667 MHz DDR4
>>
>> 在2023年8月23日星期三 UTC+8 04:31:28 写道：
>>
>>> Another question is whether this is the same the second time you
>>> create a channel. The first time, the JVM may be taking time doing
>>> class
>>> loading.
>>>
>>> On Tue, Aug 22, 2023 at 8:41 AM 'Yuri Golobokov' via grpc.io <
>>> grp...@googlegroups.com> wrote:
>>>
Hello,
What is the round-trip time? How much time does DNS resolution take?
On Tuesday, August 22, 2023 at 12:02:21 AM UTC-7 邹会江 wrote:
> ### JAVA Code
>
> ```
> channel =
> ManagedChannelBuilder.forTarget(param.getTarget()).build();
> long channelStart = System.currentTimeMillis();
> asyncStub = ASRRouteGrpc.newStub(channel);
> asrResponseStreamObserver = new
> ASRResponseStreamObserver(speechTranscriberListener);
> requestObserver =
> asyncStub.route(asrResponseStreamObserver);
> RouteRequest requestConf = newRequestHead(param);
> traceId = requestConf.getAsrConfig().getTraceId();
> ConnectivityState currentChannelState =
> channel.getState(true);
> while (currentChannelState != ConnectivityState.READY)
> {
> CountDownLatch latchUntilChannelReady = new
