[grpc-io] Re: RpcException when calling MoveNext C#

[tyczj359]

Here is the server code

class Program
{
static void Main(string[] args)
{
Server server = new Server
{
Services = { Logger.Logger.BindService(new LoggerImp()) },
Ports = { new ServerPort("192.168.1.223", 50051, 
ServerCredentials.Insecure) }
};
server.Start();


Console.WriteLine("Greeter server listening on port " + 50051);
Console.WriteLine("Press any key to stop the server...");
Console.ReadKey();


server.ShutdownAsync().Wait();
}
}


class LoggerImp : Logger.Logger.LoggerBase
{
private HashSet> listeners = new 
HashSet>();


public override Task ListenForMessages(LogListener request, 
IServerStreamWriter responseStream, ServerCallContext context)
{
return base.ListenForMessages(request, responseStream, context);
}


public override async Task SendLogMessages(IAsyncStreamReader<
LogMessage> requestStream, IServerStreamWriter responseStream, 
ServerCallContext context)
{
listeners.Add(responseStream);


while (await requestStream.MoveNext())
{
var current = requestStream.Current;
if (current.ClientType == 1)
{
listeners.Add(responseStream);
}


foreach (IServerStreamWriter listener in 
listeners)
{
try
{
await listener.WriteAsync(current);
}
catch (Exception)
{
//client stream no longer exists so remove it from 
list of active streams
listeners.Remove(listener);
}


}
}
}
}

The server will throw an error on the line 

await listener.WriteAsync(current); 

if the stream is no longer active (ie. I stopped the wpf app, started it 
again and the server tries to send a message to a stream that does not 
exist) I expected this but when this happens this also throws that 
RpcException in the Wpf app which I didn't think would happen because I am 
catching the exception on the server when I try to write to the stream but 
it still seems to propagate back to the client.

What I am trying to do is keep a list of all streams of a certain client 
type, these streams then see any message that comes in from any client.

On Wednesday, October 3, 2018 at 4:28:10 PM UTC-4, Benjamin Krämer wrote:
>
> Looks to my like the server side threw an exception. Can you also paste 
> the server side?
>

-- 
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/435965fc-c198-4851-b1be-65294f5f9540%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Non experimental way to allow a client to gracefully cancel streaming service in Java

[sankate via grpc.io]

 

Since all StreamObserver (CallStreamObserver, ServerCallStreamObserver) 
classes are marked as experimental 
https://github.com/grpc/grpc-java/issues/1788 , What is a stable way to 
allow a client to gracefully cancel streaming service by signaling the 
server to stop sending messages?

Also, if I decide to use these experimental classes to achieve this 
functionality, can I assume that I will be fine unless I upgrade grpc-java 
version?


I have tried to seach for the answer on Stackoverflow and this group but 
could not get a concrete answer. Ideally this should be documented as part 
of gRPC official documentation. 


Thanks,

Sankate

-- 
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/8fc7ff36-275a-458f-a9bc-c3642eac00f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] grpc-web

['Stanley Cheung' via grpc.io]

This is from https://github.com/improbable-eng/grpc-web right? Please
contact the maintainers of that project. Thanks!

On Sat, Sep 29, 2018 at 2:45 AM Naveed rajput 
wrote:

> Hi, i am facing problem in ts-protoc-gen
>
> //error
>  protoc
> --plugin=protoc-gen-js_service=./node_modules/.bin/protoc-gen-js_service
> --js_out=import_style=commonjs,binary:generated --js_service_out=generated
> books.proto
> --js_service_out: protoc-gen-js_service: %1 is not a valid Win32
> application.
>
> please send me the solutions to this problem! thank you
>
> --
> 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/c390f0e6-1164-4608-afa7-2ecdb43ebd20%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/CAEteGX1JXfa8Bcs24s9XT9_AguVMuCcW-QD%3DGnx2DMpYPrZ%3Dkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: RpcException when calling MoveNext C#

[Benjamin Krämer]

If you have a look at 
https://github.com/grpc/grpc/blob/master/src/csharp/Grpc.Core/Internal/ServerCallHandler.cs#L340
 
this usually happens if the server throws any exception that is not of the 
type RpcException.

-- 
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/f4ee122d-55da-4b83-955f-666aa657f321%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: RpcException when calling MoveNext C#

[Benjamin Krämer]

Looks to my like the server side threw an exception. Can you also paste the 
server side?

-- 
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/d2e1d1d0-ae35-4906-bca0-9b47a466c2a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: is this the correct way of using grpc ?

[Benjamin Krämer]

You can use the Any type with any proto message.Since PersonFilter is now a 
proto message and not any java class, it should definetly work. You should 
also check the type of the any before deserializing it if you want to 
support multiple ones. Not sure how this looks like in Java since I'm 
mostly working with C#, but as Carl already said, the message type is 
encoded as string and therefore the dumbest way would be a string 
comparison to the full name of the message type.

If you only have PersonFilter and don't need the flexibility, you should 
definetly use PersonFilter as type of the field and not bytes or Any. This 
makes usability of the API a lot easier and safer.

-- 
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/e726fa33-fe33-4fe0-85a8-a85dcca7459c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: is this the correct way of using grpc ?

['Carl Mastrangelo' via grpc.io]

Responses inline

On Wednesday, October 3, 2018 at 5:04:07 AM UTC-7, omid pourhadi wrote:
>
> Thank you.
>
> I had the same conversation here 
>
> https://groups.google.com/forum/#!topic/protobuf/JwiAkWbEAYI
>
> and I came to conclusion that Any is for messages with type and it is not 
> good for java serialization I tried it and I got this error.
> Type of the Any message does not match the given class.
>
>
>
You  need to serialize and deserialize with the same Java class in order 
for it to work.  The Any message contains both the bytes and the message 
type (as a string) which is how it knows to raise an error.

 

> Another problem is, since I don't know how to convert bytes (ByteString 
> proto in Java) in message to Java Object I had to manually parse the protos 
> in my application code here.
>
> https://github.com/omidp/grpc-crud/blob/master/grpc-server/src/main/java/com/omid/grpc/service/PersonServiceImpl.java#L68
>  
> 
>
> what is the correct way of doing this ?
>

In your proto, request.getSearch().getFilter() is being treated as bytes.  
You need to declare that field as the message you want. 

>
>
>
> On Wednesday, October 3, 2018 at 3:27:26 AM UTC+3:30, Benjamin Krämer 
> wrote:
>>
>> It looks like you wanted to keep the Pagination message independant of 
>> your Person message in 
>> https://github.com/omidp/grpc-crud/blob/master/grpc-proto/src/main/proto/main.proto
>>
>> Instead of doing it through bytes, you should prefer the Any type 
>> (google.protobuf.Any) which you already import but not use. This will allow 
>> you to unpack it as the correct type (PersonFilter) and is internally still 
>> stored as bytes. This also works across all languages which makes porting 
>> easier. It's never a good idea to do the (de-)serialization manually.
>>
>

-- 
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/eb3f6ee4-76db-41bd-a365-88d423868dc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Is there a way to tell if Write failed because the msg is too big

['Srini Polavarapu' via grpc.io]

After the write fails, you have to call Finish() to get the status. See 
example here: https://grpc.io/docs/tutorials/async/helloasync-cpp.html


On Wednesday, September 26, 2018 at 12:17:05 PM UTC-7, dataman wrote:
>
>
> Thanks for the response! I am using the async Write. There is no status 
> returned in the call to Write itself. The Next call to the completion queue 
> has no status indication as well, except for the success/failure boolean 
> value.
>
>
> On Wednesday, September 26, 2018 at 2:05:44 PM UTC-4, Muxi Yan wrote:
>>
>> AFAIK the error detail should be included in the returned status of the 
>> call.
>>
>> On Thursday, September 20, 2018 at 7:22:49 AM UTC-7, dataman wrote:
>>>
>>>
>>> Hi all,
>>>
>>> I am working on an async gRPC client in C++. Due to server limitations 
>>> we need to cap the max send msg size in the client. When we try to send a 
>>> msg which is larger than the cap, the Write (async) fails, which is as 
>>> expected.
>>>
>>> Is there a way to know that the failure is due to the msg size and not 
>>> any other reason?
>>>
>>> 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/d84deffc-1848-4038-acac-6f9b6a8728fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] grpc++: issues with opencensus tracing [cmake]

[nathan . prat]

 

Hello,


I have some issues setting up grpc++ and Opencensus.

Before anything else, I have built grpc_opencensus_plugin(and its 
dependencies) with Cmake. Could I have missed something regarding some kind 
of static init? Dynamic linking?


Anyway, the prometheus stats are correctly exported, but I can not get the 
traces to work(both stdout and zipkin).
The traces are correctly logged/exported, but they always have the same 
“Parent SpanId: 30c6ff7f”.


Based on the stacktrace below, I can confirm one of CensusContext’s 
constructors is indeed called for each request, but it calls 
StartSpanWithRemoteParent instead of StartSpan.

The result is that in zipkin, I basically have only one “meta span” for the 
whole duration of the server. That span is typically 200-300s, depending on 
how often I restart the server(local dev server).


Example: I start something in the client, a span with 2-3 requests appears 
in zipkin. Then 5 minutes later, I do something else client side and the 
same span will be modified, and now have a duration of 300s.


grpc::CensusContext::CensusContext(grpc::CensusContext * this, 
> absl::string_view name, const opencensus::trace::SpanContext & parent_ctxt) 
> (grpc/src/cpp/ext/filters/census/context.h:54)
>
> grpc::GenerateServerContext(absl::string_view tracing, absl::string_view 
> stats, absl::string_view primary_role, absl::string_view method, 
> grpc::CensusContext * context) 
> (grpc/src/cpp/ext/filters/census/context.cc:34)
>
> grpc::CensusServerCallData::OnDoneRecvInitialMetadataCb(void * user_data, 
> grpc_error * error) 
> (grpc/src/cpp/ext/filters/census/server_filter.cc:113)
>
> exec_ctx_run(grpc_closure * closure, grpc_error * error) 
> (grpc/src/core/lib/iomgr/exec_ctx.cc:40)
>
> grpc_closure_run(const char * file, int line, grpc_closure * c, grpc_error 
> * error) (grpc/src/core/lib/iomgr/closure.h:258)
>
> recv_initial_metadata_ready(void * arg, grpc_error * error) 
> (grpc/src/core/ext/filters/deadline/deadline_filter.cc:298)
>
> exec_ctx_run(grpc_closure * closure, grpc_error * error) 
> (grpc/src/core/lib/iomgr/exec_ctx.cc:40)
>
> grpc_closure_run(const char * file, int line, grpc_closure * c, grpc_error 
> * error) (grpc/src/core/lib/iomgr/closure.h:258)
>
> hs_recv_initial_metadata_ready(void * user_data, grpc_error * err) 
> (grpc/src/core/ext/filters/http/server/http_server_filter.cc:289)
>
> exec_ctx_run(grpc_closure * closure, grpc_error * error) 
> (grpc/src/core/lib/iomgr/exec_ctx.cc:40)
>
> grpc_core::ExecCtx::Flush(grpc_core::ExecCtx * this) 
> (grpc/src/core/lib/iomgr/exec_ctx.cc:134)
>
> pollset_work(grpc_pollset * pollset, grpc_pollset_worker ** worker_hdl, 
> grpc_millis deadline) (grpc/src/core/lib/iomgr/ev_epollex_linux.cc:1195)
>
> pollset_work(grpc_pollset * pollset, grpc_pollset_worker ** worker, 
> grpc_millis deadline) (grpc/src/core/lib/iomgr/ev_posix.cc:313)
>
> grpc_pollset_work(grpc_pollset * pollset, grpc_pollset_worker ** worker, 
> grpc_millis deadline) (grpc/src/core/lib/iomgr/pollset.cc:48)
>
> cq_next(grpc_completion_queue * cq, gpr_timespec deadline, void * 
> reserved) (grpc/src/core/lib/surface/completion_queue.cc:1030)
>
> grpc_completion_queue_next(grpc_completion_queue * cq, gpr_timespec 
> deadline, void * reserved) 
> (grpc/src/core/lib/surface/completion_queue.cc:1106)
>
> grpc::CompletionQueue::AsyncNextInternal(grpc::CompletionQueue * this, 
> void ** tag, bool * ok, gpr_timespec deadline) 
> (grpc/src/cpp/common/completion_queue_cc.cc:56)
>
> grpc::CompletionQueue::Next(grpc::CompletionQueue * this, void ** tag, 
> bool * ok) (grpc/include/grpcpp/impl/codegen/completion_queue.h:171)
>
> ServerImpl::HandleRpcs(ServerImpl * this) 
> (.../grpc_servers/api_server_async.cpp:105)
>
> ServerImpl::Run(ServerImpl * this, const std::__cxx11::string & 
> server_address) (.../grpc_servers/api_server_async.cpp:69)
>


What can I do to have 1 span per request? 

Should I instrument the route manually? But in that case what is the point 
of the census plugin?

Should this come from the client?


PS: I don’t know if that is relevant, but I’m using the async routes(unary, 
not streaming).

PS2: the stats(prometheus) works fine

PS3: client is grpc-java, android

-- 
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/bf4b62d5-7aac-45d8-8363-ab919ead45ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: is this the correct way of using grpc ?

[omid pourhadi]

Thank you.

I had the same conversation here 

https://groups.google.com/forum/#!topic/protobuf/JwiAkWbEAYI

and I came to conclusion that Any is for messages with type and it is not 
good for java serialization I tried it and I got this error.
Type of the Any message does not match the given class.


Another problem is, since I don't know how to convert bytes (ByteString 
proto in Java) in message to Java Object I had to manually parse the protos 
in my application code here.
https://github.com/omidp/grpc-crud/blob/master/grpc-server/src/main/java/com/omid/grpc/service/PersonServiceImpl.java#L68

what is the correct way of doing this ?



On Wednesday, October 3, 2018 at 3:27:26 AM UTC+3:30, Benjamin Krämer wrote:
>
> It looks like you wanted to keep the Pagination message independant of 
> your Person message in 
> https://github.com/omidp/grpc-crud/blob/master/grpc-proto/src/main/proto/main.proto
>
> Instead of doing it through bytes, you should prefer the Any type 
> (google.protobuf.Any) which you already import but not use. This will allow 
> you to unpack it as the correct type (PersonFilter) and is internally still 
> stored as bytes. This also works across all languages which makes porting 
> easier. It's never a good idea to do the (de-)serialization manually.
>

-- 
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/76bbb0ed-0534-403a-9cb6-3b3d4c786b0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRPC interoperable C++ server framework without C++11 ?

[Robert Bielik]

Hi all,

Is there some C++ framework available without need for C++11 that is 
interoperable with gRPC clients ? 

We've had a request from a customer who still hangs on to an ancient gcc 
without C++11... :(

Regards
/Robert

-- 
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/47adb9f6-4789-403a-badb-4a7979686898%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.