date:20180910

[grpc-io] Re: Scala gRPC High CPU Utilization

2018-09-10 Thread 'Kos' via grpc.io

Hey Carl,

Yup the way you've described it is exactly how I have it setup. 

private def channelBuilder(address: String): ManagedChannel = {
  val interceptor = 
MonitoringClientInterceptor.create(Configuration.allMetrics())
  val builder = NettyChannelBuilder
.forAddress(address, 
realtimePublishProxyConfig.realtimeInstanceConfig.realtimeServicePort)
.intercept(interceptor)
.executor(ForkJoinPool.commonPool())
.eventLoopGroup(nioEventLoopGroup)

  clientSslContext match {
case Some(sslContext) => 
builder.sslContext(sslContext).useTransportSecurity()
case None => builder.usePlaintext(true)
  }

  builder.build()
}



I just got back from PTO so going to start looking into this again. I had a 
quick question that I couldn't find much information about after doing some 
searching. Currently we send one logical request per RPC. Would there be 
advantages to sending multiple requests in one RPC (i.e batching)? Our 
server would likely convert the batch RPC into individual requests so we 
wouldn't be able to take advantage of batching throughout the system. So my 
question is more targeted towards gRPC and how it handles this. 

Thanks!

On Friday, August 31, 2018 at 4:06:18 PM UTC-7, Carl Mastrangelo wrote:
>
> It should be one ManagedChannel per host*.  There are a lot of batching 
> opportunities possible when using just one channel.  For example, TLS 
> encryption can work on larger block sizes at a time.  Another example is 
> that netty can poll on fewer threads, meaning fewer wakeups across all your 
> threads.  Just to make sure we are on the same page:
>
> - Only use one ManagedChannel per "target"  (a.k.a. hostname)
> - Use a limited executor (like ForkJoinPool) for each channel.  You can 
> share this executor across channels if your RPCs don't block very long
> - Use a single Netty EventLoopGroup, and limit the number of loops.  You 
> can share the group across all your channels.
> - Use Netty tcnative for SSL / TLS if you aren't already.  This is 
> enormously faster than the SSL that comes with the JDK.
>
> These also apply the server as well.
>
>
> * there are rare cases to break this rule, but they don't sound like they 
> apply to your usage.
>
> On Friday, August 31, 2018 at 2:02:18 PM UTC-7, Kos wrote:
>>
>> Hi Carl,
>>
>> I did run a Yourkit run against my service and what I see is many threads 
>> being created for the event loop group - they're all named something like: 
>> 'grpc-default-worker-ELG-...'. I did some reading on your other posts and 
>> saw you recommended using an ELG bounded to 1-2 threads. I tried this and I 
>> see our CPU utilization drop by about 10-15% with no loss in throughput! 
>>
>> This got me thinking and I'm wondering if my problem is actually having 
>> too many managed channels? Some background, this service creates a managed 
>> channel per each node that it talks to (about 40 or so). For the traffic it 
>> receives, it does some filtering and sends the data down N of those 
>> channels. This outbound throughput is quite low - on the order of 10k/sec 
>> across all the channels. All of these managed channels now share the same 
>> NIO ELG and they use the same ForkJoinPool.commonPool as you recommend. I'm 
>> wondering though if one managed channel per host is the correct approach 
>> here? Or should I make my own 'ManagedChannel' and create a subchannel per 
>> host?
>>
>> Thanks!
>>
>>
>>
>>
>>
>> On Wednesday, August 29, 2018 at 2:28:00 PM UTC-7, Carl Mastrangelo wrote:
>>>
>>> More info is needed to figure out why this is slow.  Have you use 
>>> JProfiler or Yourkit before?  There are a couple Java profilers (perf, 
>>> even) that can tell you where the CPU is going to.  Also, you should 
>>> consider turning on gc logging to see if memory is being consumed too 
>>> fast.  
>>>
>>> Our tuned benchmarks get about 5000qps per core, but that took profiling 
>>> before we could get that fast.   The general approach is figure out whats 
>>> slow, and then fix that.   Without knowing whats slow for your test, its 
>>> hard to recommend a fix.
>>>
>>> On Tuesday, August 28, 2018 at 2:14:31 PM UTC-7, kaus...@box.com wrote:

 Hi Carl,

 Thanks for responding! I've tried a couple different executors and they 
 don't seem to change the behavior. I've done FixedThreadPool with the 
 number of threads = # of cores * 2, the ForkJoinPool.commonPool as you 
 recommended, and the Scala global ExecutionContext which ultimately is a 
 ForkJoinPool as well. I've set this in the NettyServerBuilder as well as 
 the call to bind my service.  

 For some more information, here's results from a gatling test run that 
 lasted 10 minutes using the CommonPool. Server implementation now looks 
 like this:

 val realtimeServiceWithMonitoring =
   ServerInterceptors.intercept(
 RealtimePublishGrpc.bindService(realtimeService, 
 ExecutionContext.global),

[grpc-io] Re: Repeated field is empty on the client side even though it is set on the server side

2018-09-10 Thread jiongjiongfly

Finally it worked after running command below, though the reason for this 
issue is not clear: 

killall python

Thanks & Best Wishes!
Jiongjiong Li


On Tuesday, September 11, 2018 at 1:35:29 AM UTC+8, Carl Mastrangelo wrote:
>
> As a sanity check, are the client and server both using the same generated 
> code?  Protobuf will ignore fields it doesn't know about by default.  In 
> your case, it sounds like you may have modified the proto on one side.  Is 
> this the case?
>
> On Monday, September 10, 2018 at 3:05:24 AM UTC-7, jiongj...@gmail.com 
> wrote:
>>
>> The repeated field of protobuf message is always empty on the gRPC client 
>> side even though I set it on the gRPC server side.
>> Is there any way to fix this issue?
>>
>>
>>
>>- helloworld.proto file:
>>
>> syntax = "proto3";
>>
>> package helloworld;
>>
>> // The greeting service definition.
>>service Greeter {
>>  // Sends a greeting.
>>  rpc SayHello (HelloRequest) returns (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;
>>  repeated string snippets = 2;
>>}
>>
>>
>>
>>
>>
>>- server.py
>>
>> from __future__ import absolute_import
>>from __future__ import division
>>from __future__ import print_function
>>
>> from concurrent import futures
>>import time
>>
>> import grpc
>>
>> import grpc_demo.lib.protos.helloworld_pb2 as helloworld_pb2
>>import grpc_demo.lib.protos.helloworld_pb2_grpc as helloworld_pb2_grpc
>>
>>
>> _ONE_DAY_IN_SECONDS = 60 * 60 * 24
>>
>> class Greeter(helloworld_pb2_grpc.GreeterServicer):
>>
>> def SayHello(self, request, context):
>>reply = helloworld_pb2.HelloReply(message='Hello, %s!' % 
>> request.name)
>>reply.snippets.append('test-snippets')
>># print('reply:' + reply)
>>return reply
>>
>> def main():
>>"""Main entrance."""
>>
>> server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
>>helloworld_pb2_grpc.add_GreeterServicer_to_server(Greeter(), 
>> server)
>>server.add_insecure_port('[::]:50051')
>>server.start()
>>try:
>>while True:
>>time.sleep(_ONE_DAY_IN_SECONDS)
>>except KeyboardInterrupt:
>>server.stop(0)
>>
>>
>> if __name__ == '__main__':
>>main()
>>
>>
>>
>>
>>
>>- client.py
>>
>> from __future__ import absolute_import
>>from __future__ import division
>>from __future__ import print_function
>>
>> import grpc
>>
>> import grpc_demo.lib.protos.helloworld_pb2 as helloworld_pb2
>>import grpc_demo.lib.protos.helloworld_pb2_grpc as helloworld_pb2_grpc
>>
>> def main():
>>"""Main entrance."""
>>
>> # NOTE(gRPC Python Team): .close() is possible on a channel and 
>> should be
>># used in circumstances in which the with statement does not fit 
>> the needs
>># of the code.
>>with grpc.insecure_channel('localhost:50051') as channel:
>>stub = helloworld_pb2_grpc.GreeterStub(channel)
>>response = 
>> stub.SayHello(helloworld_pb2.HelloRequest(name='you'))
>>print("Greeter client received: " + response.message + ', 
>> '.join(response.snippets) 
>> + str(len(response.snippets)))
>>
>>
>> if __name__ == '__main__':
>>main()
>>
>>
>>
>>
>>- Expected Result:
>>
>>
>> *Greeter client received: Hello, you!test-snippets1*
>>
>>
>>- Actual Result:
>>
>>
>> *Greeter client received: Hello, you!0*
>>
>> Thanks!
>> Jiongjiong Li
>>
>

-- 
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/d82b51b4-2e3a-4d88-880b-f992513512f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Repeated field is empty on the client side even though it is set on the server side

2018-09-10 Thread jiongjiongfly

No, both the client and server run in the same anaconda environment and the 
proto import path are the same.

Thanks & Best Wishes!
Jiongjiong Li


On Tuesday, September 11, 2018 at 1:35:29 AM UTC+8, Carl Mastrangelo wrote:
>
> As a sanity check, are the client and server both using the same generated 
> code?  Protobuf will ignore fields it doesn't know about by default.  In 
> your case, it sounds like you may have modified the proto on one side.  Is 
> this the case?
>
> On Monday, September 10, 2018 at 3:05:24 AM UTC-7, jiongj...@gmail.com 
> wrote:
>>
>> The repeated field of protobuf message is always empty on the gRPC client 
>> side even though I set it on the gRPC server side.
>> Is there any way to fix this issue?
>>
>>
>>
>>- helloworld.proto file:
>>
>> syntax = "proto3";
>>
>> package helloworld;
>>
>> // The greeting service definition.
>>service Greeter {
>>  // Sends a greeting.
>>  rpc SayHello (HelloRequest) returns (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;
>>  repeated string snippets = 2;
>>}
>>
>>
>>
>>
>>
>>- server.py
>>
>> from __future__ import absolute_import
>>from __future__ import division
>>from __future__ import print_function
>>
>> from concurrent import futures
>>import time
>>
>> import grpc
>>
>> import grpc_demo.lib.protos.helloworld_pb2 as helloworld_pb2
>>import grpc_demo.lib.protos.helloworld_pb2_grpc as helloworld_pb2_grpc
>>
>>
>> _ONE_DAY_IN_SECONDS = 60 * 60 * 24
>>
>> class Greeter(helloworld_pb2_grpc.GreeterServicer):
>>
>> def SayHello(self, request, context):
>>reply = helloworld_pb2.HelloReply(message='Hello, %s!' % 
>> request.name)
>>reply.snippets.append('test-snippets')
>># print('reply:' + reply)
>>return reply
>>
>> def main():
>>"""Main entrance."""
>>
>> server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
>>helloworld_pb2_grpc.add_GreeterServicer_to_server(Greeter(), 
>> server)
>>server.add_insecure_port('[::]:50051')
>>server.start()
>>try:
>>while True:
>>time.sleep(_ONE_DAY_IN_SECONDS)
>>except KeyboardInterrupt:
>>server.stop(0)
>>
>>
>> if __name__ == '__main__':
>>main()
>>
>>
>>
>>
>>
>>- client.py
>>
>> from __future__ import absolute_import
>>from __future__ import division
>>from __future__ import print_function
>>
>> import grpc
>>
>> import grpc_demo.lib.protos.helloworld_pb2 as helloworld_pb2
>>import grpc_demo.lib.protos.helloworld_pb2_grpc as helloworld_pb2_grpc
>>
>> def main():
>>"""Main entrance."""
>>
>> # NOTE(gRPC Python Team): .close() is possible on a channel and 
>> should be
>># used in circumstances in which the with statement does not fit 
>> the needs
>># of the code.
>>with grpc.insecure_channel('localhost:50051') as channel:
>>stub = helloworld_pb2_grpc.GreeterStub(channel)
>>response = 
>> stub.SayHello(helloworld_pb2.HelloRequest(name='you'))
>>print("Greeter client received: " + response.message + ', 
>> '.join(response.snippets) 
>> + str(len(response.snippets)))
>>
>>
>> if __name__ == '__main__':
>>main()
>>
>>
>>
>>
>>- Expected Result:
>>
>>
>> *Greeter client received: Hello, you!test-snippets1*
>>
>>
>>- Actual Result:
>>
>>
>> *Greeter client received: Hello, you!0*
>>
>> Thanks!
>> Jiongjiong Li
>>
>

-- 
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/a302f9bb-0d4c-4026-94ae-bee6f5591d2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] [Java] Correct way to terminate call in a ServerInterceptor?

2018-09-10 Thread Jacques

Hello,

I have a GRPC protocol I'm working on where I want the ServerInterceptor to 
terminate the call if I find the metadata invalid. What is the correct way 
to do it while returning an appropriate status code (permission denied in 
this case). I'm currently calling call.close() in the interceptor but then 
returning the original next.startCall(). The next.startCall() throws an 
exception because it is trying to work against a now closed connection. The 
method declaration doesn't allow throwing a StatusException. I'm sure there 
is an example of this somewhere but I didn't run across it. Example of 
current code below:

public class ServerAuthInterceptor implements ServerInterceptor {


  @Override

  public  Listener interceptCall(ServerCall 
call, Metadata headers,

  ServerCallHandler next) {

if (!MyThing.isValid(headers)) {

  call.close(Status.PERMISSION_DENIED, new Metadata());

  // TODO: what do we return here to avoid the exception caused by 
startCall below?

}


return next.startCall(call, headers);

  }


}


Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e039927e-163c-489f-9fc6-e6634fe2d088%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Seg Fault when calling grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest

2018-09-10 Thread 'Vijay Pai' via grpc.io

 In particular, a reason that this is likely to fail out is that your 
listening port is #1000 , which will only work if you are root.

On Monday, September 10, 2018 at 3:35:33 PM UTC-7, Yang Gao wrote:
>
> The first thing I would check is whether server_ == nullptr after 
> BuildAndStart.
>
> On Mon, Sep 10, 2018 at 3:22 PM Alistair Lowe  > wrote:
>
>> Hi guys,
>>
>> I'm trying to implement my own gRPC 1.14.2 C++ async server loosely 
>> following the hello world examples, however I receive a segfault when 
>> attempting to make an asynchronous request as per the below stack trace:
>>
>> grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest(void*, 
>> grpc_byte_buffer**, grpc::ServerCompletionQueue*) (Unknown Source:0)
>> grpc::ServerInterface::PayloadAsyncRequest::PayloadAsyncRequest(grpc::ServerInterface::PayloadAsyncRequest
>>  
>> * const this, void * registered_method, grpc::ServerInterface * server, 
>> grpc::ServerContext * context, 
>> grpc::internal::ServerAsyncStreamingInterface * stream, 
>> grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue * 
>> notification_cq, void * tag, OpenIoTServer::EnrollRequest * request) 
>> (/usr/local/include/grpcpp/impl/codegen/server_interface.h:212)
>> grpc::ServerInterface::RequestAsyncCall(grpc::ServerInterface
>>  
>> * const this, grpc::internal::RpcServiceMethod * method, 
>> grpc::ServerContext * context, 
>> grpc::internal::ServerAsyncStreamingInterface * stream, 
>> grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue * 
>> notification_cq, void * tag, OpenIoTServer::EnrollRequest * message) 
>> (/usr/local/include/grpcpp/impl/codegen/server_interface.h:275)
>> grpc::Service::RequestAsyncUnary(grpc::Service 
>> * const this, int index, grpc::ServerContext * context, 
>> OpenIoTServer::EnrollRequest * request, 
>> grpc::internal::ServerAsyncStreamingInterface * stream, 
>> grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue * 
>> notification_cq, void * tag) 
>> (/usr/local/include/grpcpp/impl/codegen/service_type.h:96)
>> OpenIoTServer::Device::WithAsyncMethod_Enroll::RequestEnroll(OpenIoTServer::Device::WithAsyncMethod_Enroll
>>  
>> * const this, grpc::ServerContext * context, OpenIoTServer::EnrollRequest * 
>> request, grpc::ServerAsyncResponseWriter * 
>> response, grpc::CompletionQueue * new_call_cq, grpc::ServerCompletionQueue 
>> * notification_cq, void * tag) 
>> (/home/developer/deployment-management-controller/device.grpc.pb.h:170)
>> main() (/home/developer/deployment-management-controller/main.cpp:81)
>>
>> I've simplified my code as much as possible and the problem is still 
>> occurring:
>> #include "device.grpc.pb.h"
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> using grpc::ServerAsyncResponseWriter;
>> using grpc::ServerBuilder;
>> using grpc::ServerContext;
>> using grpc::ServerCompletionQueue;
>> using grpc::Status;
>>
>> int main( int, char** )
>> {
>> std::unique_ptr cq_;
>> OpenIoTServer::Device::AsyncService service_;
>> std::unique_ptr server_;
>>
>> ServerBuilder serverBuilder;
>> serverBuilder.AddListeningPort( "127.0.0.1:1000", 
>> InsecureServerCredentials() );
>> serverBuilder.RegisterService( _ );
>>
>> cq_ = serverBuilder.AddCompletionQueue();
>> server_ = serverBuilder.BuildAndStart();
>> ServerContext ctx_;
>> EnrollRequest request_;
>> EnrollResponse reply_;
>> ServerAsyncResponseWriter responder_(_);
>>
>> service_.RequestEnroll(_, _, _, cq_.get(), cq_.get
>> (),(void*)1); // SEGFAULT WITHIN HERE
>> }
>>
>> My protobuf is generated from the following using protoc version 3.5.1:
>> syntax = "proto3";
>> package OpenIoTServer;
>>
>> service Device
>> {
>> rpc Enroll(EnrollRequest) returns (EnrollResponse);
>> }
>>
>> message EnrollRequest
>> {
>> bytes device_id = 1;
>> bytes user_id = 2;
>> }
>>
>> message EnrollResponse
>> {
>> bool success = 1;
>> }
>>
>> Any suggestions would be very-much appreciated!
>>
>> Many thanks
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "grpc.io" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to grpc-io+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/6cea7726-cc2b-4ea0-bdcf-1a38f6301e43%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

Re: [grpc-io] Seg Fault when calling grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest

2018-09-10 Thread 'Yang Gao' via grpc.io

The first thing I would check is whether server_ == nullptr after
BuildAndStart.

On Mon, Sep 10, 2018 at 3:22 PM Alistair Lowe  wrote:

> Hi guys,
>
> I'm trying to implement my own gRPC 1.14.2 C++ async server loosely
> following the hello world examples, however I receive a segfault when
> attempting to make an asynchronous request as per the below stack trace:
>
> grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest(void*,
> grpc_byte_buffer**, grpc::ServerCompletionQueue*) (Unknown Source:0)
> grpc::ServerInterface::PayloadAsyncRequest::PayloadAsyncRequest(grpc::ServerInterface::PayloadAsyncRequest
> * const this, void * registered_method, grpc::ServerInterface * server,
> grpc::ServerContext * context,
> grpc::internal::ServerAsyncStreamingInterface * stream,
> grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue *
> notification_cq, void * tag, OpenIoTServer::EnrollRequest * request)
> (/usr/local/include/grpcpp/impl/codegen/server_interface.h:212)
> grpc::ServerInterface::RequestAsyncCall(grpc::ServerInterface
> * const this, grpc::internal::RpcServiceMethod * method,
> grpc::ServerContext * context,
> grpc::internal::ServerAsyncStreamingInterface * stream,
> grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue *
> notification_cq, void * tag, OpenIoTServer::EnrollRequest * message)
> (/usr/local/include/grpcpp/impl/codegen/server_interface.h:275)
> grpc::Service::RequestAsyncUnary(grpc::Service
> * const this, int index, grpc::ServerContext * context,
> OpenIoTServer::EnrollRequest * request,
> grpc::internal::ServerAsyncStreamingInterface * stream,
> grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue *
> notification_cq, void * tag)
> (/usr/local/include/grpcpp/impl/codegen/service_type.h:96)
> OpenIoTServer::Device::WithAsyncMethod_Enroll::RequestEnroll(OpenIoTServer::Device::WithAsyncMethod_Enroll
> * const this, grpc::ServerContext * context, OpenIoTServer::EnrollRequest *
> request, grpc::ServerAsyncResponseWriter *
> response, grpc::CompletionQueue * new_call_cq, grpc::ServerCompletionQueue
> * notification_cq, void * tag)
> (/home/developer/deployment-management-controller/device.grpc.pb.h:170)
> main() (/home/developer/deployment-management-controller/main.cpp:81)
>
> I've simplified my code as much as possible and the problem is still
> occurring:
> #include "device.grpc.pb.h"
> #include 
> #include 
> #include 
> #include 
> #include 
>
> using grpc::ServerAsyncResponseWriter;
> using grpc::ServerBuilder;
> using grpc::ServerContext;
> using grpc::ServerCompletionQueue;
> using grpc::Status;
>
> int main( int, char** )
> {
> std::unique_ptr cq_;
> OpenIoTServer::Device::AsyncService service_;
> std::unique_ptr server_;
>
> ServerBuilder serverBuilder;
> serverBuilder.AddListeningPort( "127.0.0.1:1000",
> InsecureServerCredentials() );
> serverBuilder.RegisterService( _ );
>
> cq_ = serverBuilder.AddCompletionQueue();
> server_ = serverBuilder.BuildAndStart();
> ServerContext ctx_;
> EnrollRequest request_;
> EnrollResponse reply_;
> ServerAsyncResponseWriter responder_(_);
>
> service_.RequestEnroll(_, _, _, cq_.get(), cq_.get
> (),(void*)1); // SEGFAULT WITHIN HERE
> }
>
> My protobuf is generated from the following using protoc version 3.5.1:
> syntax = "proto3";
> package OpenIoTServer;
>
> service Device
> {
> rpc Enroll(EnrollRequest) returns (EnrollResponse);
> }
>
> message EnrollRequest
> {
> bytes device_id = 1;
> bytes user_id = 2;
> }
>
> message EnrollResponse
> {
> bool success = 1;
> }
>
> Any suggestions would be very-much appreciated!
>
> Many thanks
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/6cea7726-cc2b-4ea0-bdcf-1a38f6301e43%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/CAB1HKY5BA4sL-a-jWaoHMM73gkC1z0d47qcExib368TVc_pG5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Seg Fault when calling grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest

2018-09-10 Thread Alistair Lowe

Hi guys,

I'm trying to implement my own gRPC 1.14.2 C++ async server loosely 
following the hello world examples, however I receive a segfault when 
attempting to make an asynchronous request as per the below stack trace:

grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest(void*, 
grpc_byte_buffer**, grpc::ServerCompletionQueue*) (Unknown Source:0)
grpc::ServerInterface::PayloadAsyncRequest::PayloadAsyncRequest(grpc::ServerInterface::PayloadAsyncRequest
 
* const this, void * registered_method, grpc::ServerInterface * server, 
grpc::ServerContext * context, 
grpc::internal::ServerAsyncStreamingInterface * stream, 
grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue * 
notification_cq, void * tag, OpenIoTServer::EnrollRequest * request) 
(/usr/local/include/grpcpp/impl/codegen/server_interface.h:212)
grpc::ServerInterface::RequestAsyncCall(grpc::ServerInterface
 
* const this, grpc::internal::RpcServiceMethod * method, 
grpc::ServerContext * context, 
grpc::internal::ServerAsyncStreamingInterface * stream, 
grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue * 
notification_cq, void * tag, OpenIoTServer::EnrollRequest * message) 
(/usr/local/include/grpcpp/impl/codegen/server_interface.h:275)
grpc::Service::RequestAsyncUnary(grpc::Service 
* const this, int index, grpc::ServerContext * context, 
OpenIoTServer::EnrollRequest * request, 
grpc::internal::ServerAsyncStreamingInterface * stream, 
grpc::CompletionQueue * call_cq, grpc::ServerCompletionQueue * 
notification_cq, void * tag) 
(/usr/local/include/grpcpp/impl/codegen/service_type.h:96)
OpenIoTServer::Device::WithAsyncMethod_Enroll::RequestEnroll(OpenIoTServer::Device::WithAsyncMethod_Enroll
 
* const this, grpc::ServerContext * context, OpenIoTServer::EnrollRequest * 
request, grpc::ServerAsyncResponseWriter * 
response, grpc::CompletionQueue * new_call_cq, grpc::ServerCompletionQueue 
* notification_cq, void * tag) 
(/home/developer/deployment-management-controller/device.grpc.pb.h:170)
main() (/home/developer/deployment-management-controller/main.cpp:81)

I've simplified my code as much as possible and the problem is still 
occurring:
#include "device.grpc.pb.h"
#include 
#include 
#include 
#include 
#include 

using grpc::ServerAsyncResponseWriter;
using grpc::ServerBuilder;
using grpc::ServerContext;
using grpc::ServerCompletionQueue;
using grpc::Status;

int main( int, char** )
{
std::unique_ptr cq_;
OpenIoTServer::Device::AsyncService service_;
std::unique_ptr server_;

ServerBuilder serverBuilder;
serverBuilder.AddListeningPort( "127.0.0.1:1000", InsecureServerCredentials() 
);
serverBuilder.RegisterService( _ );

cq_ = serverBuilder.AddCompletionQueue();
server_ = serverBuilder.BuildAndStart();
ServerContext ctx_;
EnrollRequest request_;
EnrollResponse reply_;
ServerAsyncResponseWriter responder_(_);

service_.RequestEnroll(_, _, _, cq_.get(), cq_.get(),(
void*)1); // SEGFAULT WITHIN HERE
}

My protobuf is generated from the following using protoc version 3.5.1:
syntax = "proto3";
package OpenIoTServer;

service Device
{
rpc Enroll(EnrollRequest) returns (EnrollResponse);
}

message EnrollRequest
{
bytes device_id = 1;
bytes user_id = 2;
}

message EnrollResponse
{
bool success = 1;
}

Any suggestions would be very-much appreciated!

Many thanks

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6cea7726-cc2b-4ea0-bdcf-1a38f6301e43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Sending HTTP headers in calls from gRPC PHP client

2018-09-10 Thread tanmad21

Thank you Carl Mastrangelo. That was very helpful!

For those who may see this question in the future below is my updated code 
that works. Notice how setting the $metaData array uses the HTTP2 header 
key as the array key, and the *header value is and array containing a 
string of the value*.

$options = [
'credentials' => $this->credentialsObject,
'update_metadata' => function($metaData){
$metaData['authorization'] = ['Bearer ' . $this->token];
return $metaData;
}
];

$client = new OrganizationServiceClient($this->url,$options);

$r = new \Google\Protobuf\GPBEmpty();

list($data,$status) = $client->list($r)->wait();


On Monday, September 10, 2018 at 11:39:08 AM UTC-6, Carl Mastrangelo wrote:
>
> In gRPC, Headers and metadata are the same thing.   The formatting for 
> headers should follow normal HTTP rules, such as ignoring case for the 
> header key, and only using the right ascii letters in the value.  You can 
> find the rules here: 
> https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md 
>
>
>
> On Monday, September 10, 2018 at 9:40:53 AM UTC-7, tanm...@gmail.com 
> wrote:
>>
>>
>> I am attempting to set some HTTP headers in gRPC client call written in 
>> PHP. I cannot find anything specifying how to do this in PHP. From reading 
>> docs for other languages I have come to think that headers are specified in 
>> the client metadata. However, I can't find anything on how these should be 
>> formatted, and all the formats I try don't seem to work. Here is my code:
>>
>>
>> $options = [
>> 'credentials' => $this->credentialsObject,
>> 'update_metadata' => function($metaData){
>> $metaData['headers'] = ['Authorization' => 'Bearer ' . 
>> $this->token];
>> return $metaData;
>> }
>> ];
>> 
>> $client = new OrganizationServiceClient($this->url,$options);
>> 
>> $r = new \Google\Protobuf\GPBEmpty();
>>
>> list($data,$status) = $client->list($r)->wait();
>>
>>
>> Any help or pointers would be appreciated. I'm been working on this for a 
>> few days now and feel like I've trying everything I can think of.
>>
>> Thanks!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/69069c5b-8a22-4859-9009-3ead1a402392%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: using grpc for push notification

2018-09-10 Thread jonathandotchin

Hello everyone,

would anyone have an example in C#/.NET Core?

Thanks,

Jonathan

On Friday, March 16, 2018 at 12:45:31 PM UTC-4, Chaitanya Gangwar wrote:
>
>
> Hi All,
>
> Previous files got deleted somehow. I am uploading it again. Please use 
> this link :
>
>
> https://drive.google.com/file/d/1jqviARRz5muVCdsBjw3WPH8xSSGpXrv1/view?usp=sharing
>
> Thanks
> Chaitanya
>
> On Saturday, 23 January 2016 01:58:18 UTC+5:30, Chaitanya Gangwar wrote:
>>
>> Hi,
>>
>> I have a requirement, where  multiple clients send (register) a request 
>> to server and continue, whenever server have data, server will push the 
>> data to clients. it may be possible that server may not have data at 
>> present and will keep pushing data whenever it has. Some other thread is 
>> providing the data to server. 
>>
>> Can i do this with grpc without blocking the server and client. What i 
>> understand from grpc streaming is that client will be waiting for data till 
>> server sends out the data and after receiving the data it closes the 
>> connection.
>>
>> please help, if i can do this using grpc and if yes how should i design 
>> this.
>>
>> thanks
>> Chaitanya
>>
>>

-- 
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/f42e69b6-58e5-4320-a3d7-dea01f46d338%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Urgent Order

2018-09-10 Thread Larry Schultz

Hello
  Am Mr. Larry Schultz .I would like to place an order of from your
company to Haiti. kindly email me with your product catalog and also your
term of payment. Waiting for your prompt responses.
Thank
Larry

-- 
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/CAF8smFp4bg0tE34Yt3NyqZJoikFW%2Ba8ohCKzJvMO94yQT%2BWTFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Best practices and patterns for raising unsolicited events and implement pub/sub?

2018-09-10 Thread jonathandotchin

Hello,

have you found an answer to your question? I am also interested in 
implementing the same system.

Thanks,

Jonathan

On Wednesday, February 8, 2017 at 12:02:25 PM UTC-5, Carl Mastrangelo wrote:
>
> I am sorry, but I am not that familiar with the c# API, so I can't give 
> any advice there.
>
> On Tuesday, February 7, 2017 at 7:27:17 AM UTC-8, mai...@gmail.com wrote:
>>
>> ...any news? Did anybody set up a similar solution?
>>
>> Thanks!
>>
>> On Monday, January 30, 2017 at 12:58:21 PM UTC+1, mai...@gmail.com wrote:
>>>
>>> Hi.
>>>
>>> What is the proper way to implement unsolicited events (fired by server 
>>> toward all its clients)? Should I use a never-returning server-stream rpc 
>>> method (i.e. a "subscribe" method) in order to keep a set 
>>> of IServerStreamWriter references and use such references to reach clients 
>>> back?
>>>
>>> Same pattern should apply to a pub/sub scenario, as far as I understand.
>>>
>>> Thanks!
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e7212732-83e5-4786-b422-d3cbf4b54c78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Sending HTTP headers in calls from gRPC PHP client

2018-09-10 Thread 'Carl Mastrangelo' via grpc.io

In gRPC, Headers and metadata are the same thing.   The formatting for 
headers should follow normal HTTP rules, such as ignoring case for the 
header key, and only using the right ascii letters in the value.  You can 
find the rules 
here: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md 



On Monday, September 10, 2018 at 9:40:53 AM UTC-7, tanm...@gmail.com wrote:
>
>
> I am attempting to set some HTTP headers in gRPC client call written in 
> PHP. I cannot find anything specifying how to do this in PHP. From reading 
> docs for other languages I have come to think that headers are specified in 
> the client metadata. However, I can't find anything on how these should be 
> formatted, and all the formats I try don't seem to work. Here is my code:
>
>
> $options = [
> 'credentials' => $this->credentialsObject,
> 'update_metadata' => function($metaData){
> $metaData['headers'] = ['Authorization' => 'Bearer ' . 
> $this->token];
> return $metaData;
> }
> ];
> 
> $client = new OrganizationServiceClient($this->url,$options);
> 
> $r = new \Google\Protobuf\GPBEmpty();
>
> list($data,$status) = $client->list($r)->wait();
>
>
> Any help or pointers would be appreciated. I'm been working on this for a 
> few days now and feel like I've trying everything I can think of.
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/0bbbfb60-8648-4cc1-ab5e-8bb52bd17ea0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Sending HTTP headers in calls from gRPC PHP client

2018-09-10 Thread tanmad21


I am attempting to set some HTTP headers in gRPC client call written in 
PHP. I cannot find anything specifying how to do this in PHP. From reading 
docs for other languages I have come to think that headers are specified in 
the client metadata. However, I can't find anything on how these should be 
formatted, and all the formats I try don't seem to work. Here is my code:


$options = [
'credentials' => $this->credentialsObject,
'update_metadata' => function($metaData){
$metaData['headers'] = ['Authorization' => 'Bearer ' . 
$this->token];
return $metaData;
}
];

$client = new OrganizationServiceClient($this->url,$options);

$r = new \Google\Protobuf\GPBEmpty();

list($data,$status) = $client->list($r)->wait();


Any help or pointers would be appreciated. I'm been working on this for a 
few days now and feel like I've trying everything I can think of.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/9569225f-dadb-44c1-9686-6a3891534a54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Using DNS Authority in C# client

2018-09-10 Thread Benjamin Krämer

You would also have to register the resolver. You can have a look at my PR 
that wasn't merged yet since it's still undecided how the API should look 
like:
https://github.com/grpc/grpc/pull/13639/files

-- 
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/34634d80-bf2c-419f-bd9f-b19a8c3acf87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Using DNS Authority in C# client

2018-09-10 Thread coderharish

Hi Benjamin,

sorry for hijacking this old thread, I understood about your point 
regarding adding own resolver. I have wrote my own resolver in cpp and now 
I am using `GRPC_DNS_RESOLVER ` to tell the gRPC to pick my resolver. But I 
gRPC is not picking the resolver, it is always `native`. Do you know why ?

On Wednesday, December 6, 2017 at 9:48:38 AM UTC+1, Benjamin Krämer wrote:
>
> Just because it's related, I have an open issue (Name resolver support 
> for C# missing ) which also 
> has all those links in it and which I use for keeping this topic together 
> and up2date. So you could subscribe to it to be notified when there is a 
> good option in addition to Making c-ares work under Windows 
> .
>
> And another thing I'm impatiently waiting for is Support for interceptors 
> in C# . So in case you need to 
> do something like logging, this issue could also be of interest to you.
>
> Other then that, I'm also hoping there will be an information about the 
> roadmap of those issues :)
>

-- 
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/6f762f4b-bc4a-4bab-b659-7263e2c2ee71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Repeated field is empty on the client side even though it is set on the server side

2018-09-10 Thread jiongjiongfly

The repeated field of protobuf message is always empty on the gRPC client 
side even though I set it on the gRPC server side.
Is there any way to fix this issue?



   - helloworld.proto file:
   
syntax = "proto3";

package helloworld;

// The greeting service definition.
   service Greeter {
 // Sends a greeting.
 rpc SayHello (HelloRequest) returns (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;
 repeated string snippets = 2;
   }





   - server.py
   
from __future__ import absolute_import
   from __future__ import division
   from __future__ import print_function

from concurrent import futures
   import time

import grpc

import grpc_demo.lib.protos.helloworld_pb2 as helloworld_pb2
   import grpc_demo.lib.protos.helloworld_pb2_grpc as helloworld_pb2_grpc


_ONE_DAY_IN_SECONDS = 60 * 60 * 24

class Greeter(helloworld_pb2_grpc.GreeterServicer):

def SayHello(self, request, context):
   reply = helloworld_pb2.HelloReply(message='Hello, %s!' % request.
name)
   reply.snippets.append('test-snippets')
   # print('reply:' + reply)
   return reply

def main():
   """Main entrance."""

server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
   helloworld_pb2_grpc.add_GreeterServicer_to_server(Greeter(), server)
   server.add_insecure_port('[::]:50051')
   server.start()
   try:
   while True:
   time.sleep(_ONE_DAY_IN_SECONDS)
   except KeyboardInterrupt:
   server.stop(0)


if __name__ == '__main__':
   main()





   - client.py
   
from __future__ import absolute_import
   from __future__ import division
   from __future__ import print_function

import grpc

import grpc_demo.lib.protos.helloworld_pb2 as helloworld_pb2
   import grpc_demo.lib.protos.helloworld_pb2_grpc as helloworld_pb2_grpc

def main():
   """Main entrance."""

# NOTE(gRPC Python Team): .close() is possible on a channel and 
should be
   # used in circumstances in which the with statement does not fit the 
needs
   # of the code.
   with grpc.insecure_channel('localhost:50051') as channel:
   stub = helloworld_pb2_grpc.GreeterStub(channel)
   response = stub.SayHello(helloworld_pb2.HelloRequest(name='you'))
   print("Greeter client received: " + response.message + ', 
'.join(response.snippets) 
+ str(len(response.snippets)))


if __name__ == '__main__':
   main()




   - Expected Result:
   

*Greeter client received: Hello, you!test-snippets1*


   - Actual Result:
   

*Greeter client received: Hello, you!0*

Thanks!
Jiongjiong Li

-- 
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/621d0a95-d098-4b93-9ac4-45a1e82abdb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Scala gRPC High CPU Utilization

[grpc-io] Re: Repeated field is empty on the client side even though it is set on the server side

[grpc-io] Re: Repeated field is empty on the client side even though it is set on the server side

[grpc-io] [Java] Correct way to terminate call in a ServerInterceptor?

Re: [grpc-io] Seg Fault when calling grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest

Re: [grpc-io] Seg Fault when calling grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest

[grpc-io] Seg Fault when calling grpc::ServerInterface::RegisteredAsyncRequest::IssueRequest

[grpc-io] Re: Sending HTTP headers in calls from gRPC PHP client

[grpc-io] Re: using grpc for push notification

[grpc-io] Urgent Order

[grpc-io] Re: Best practices and patterns for raising unsolicited events and implement pub/sub?

[grpc-io] Re: Sending HTTP headers in calls from gRPC PHP client

[grpc-io] Sending HTTP headers in calls from gRPC PHP client

[grpc-io] Re: Using DNS Authority in C# client

[grpc-io] Re: Using DNS Authority in C# client

[grpc-io] Repeated field is empty on the client side even though it is set on the server side

16 matches

Site Navigation

Mail list logo

Footer information