I'm having a GRPC service written in Go that wraps a C++ library.
Now, once in a while, the server hangs on a grpcurl based client call, while it succeeds at other times in sending out a response.
I have tried exporting the grpc traces variable and setting the verbosity to DEBUG, but they didn't seem to help.
Related
This is surely a weird one ... I'm doing some extreme integration style testing on a custom Java HTTP client for a backend service I'm working with. For reasons which don't matter here, the client has some specific quirks and a custom solution was the only real option.
For automated testing, I've built a "fake" version of the backend service by spinning up a Jetty server locally and having it behave in different ways e.g. return 500, wait e.g. 4 seconds before giving a response to simulate latency etc and firing off a battery of tests against it with the client on build time.
Given the nature of this client, there is an usual and specific scenario which I need to test and I'm trying to find a way to make my Jetty serve behave in the correct fashion. Basically, when returning HTTP response, I need to immediately return the HTTP Headers and the first few bytes of the HTTP body and then sleep. The goal is to trigger a socket timeout in the client specifically when reading the HTTP body.
Anyone know where in Jetty I could plug something in to force this behaviour? Was looking at the Connector interface but not so sure thats the right place.
Thanks for any suggestions.
Write a few bytes to the HttpServletResponse.getOutputStream(), then call HttpServletResponse.flushBuffer() to immediately commit the response.
Bonus tip: use HttpServletResponse.sendError(-1) to terminate the connection abruptly.
We have a framework that communicates via native WinAPI sockets (WSASend , CompletionPorts, etc) via TCP.
Recently, we've added some classes to this framework that also async sends and receives some messages via UDP, but these classes use Boost.ASIO (io_context etc).
Since then, we noticed that WinSocks connect function fails, with the following error:
A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection
failed because connected host has failed to respond. The thread 0x3038
has exited with code 0 (0x0)
This only fails when connecting to a remote computer, not locally.
When reverting to an older version without these Boost classes, everything works fine (ruling out firewall issues)
When the Boost.ASIO classes our used outside of the framework, they work fine.
We are unsure what causes this issue. My hunch is that it is a conflict on OS level between winsock and boost.ASIO.
Did anyone run into something similar? Any ideas or pointers would be really appreciated.
Ben
Using the grpc version 1.38.0, compiled on CentOS 7 from sources with gcc version 9.4.0 and cmake version 3.19.6 (with all the cmake dependencies set to "module"), the following code taken from the grpc documentation site:
auto channel_creds = grpc::SslCredentials(grpc::SslCredentialsOptions());
auto channel = grpc::CreateChannel(server_name, channel_creds);
compiles, links, runs, does not coredump but the respective grpc calls executed against that channel all fail with the following error message:
E0816 17:49:03.236686130 14443 ssl_transport_security.cc:1468] Handshake failed with fatal error SSL_ERROR_SSL: error:100000f7:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER.
Since the referenced above google's documentation sample that implements
the simplest authentication scenario, where a client just wants to authenticate the server and encrypt all data
is taken to be complete, the respective grpc c++ server was bound to a needed port via the grpc::InsecureServerCredentials() option.
Clearly, either the sample code is not complete or some other instructions on how to implement "the simplest authentication scenario, where a client just wants to authenticate the server and encrypt all data" are missing.
Question: could someone please provide a complete c++ code that must be written on both the grpc c++ client side and the grpc c++ server side so that the much advertised "simplest authentication scenario, where a client just wants to authenticate the server and encrypt all data" actually works and the encrypted bytes do flow over the wire from a grpc c++ client to its grpc c++ server and the said grpc c++ server decrypts these bytes and passes them onto the underlying application? Along with any other non code instructions if those are needed.
Changing the code on the grpc c++ server side to use the grpc::SslServerCredentials( grpc::SslServerCredentialsOptions() ) leads to a code that compiles, links, runs but quickly dumps core with the following error message:
E0816 19:24:26.270527688 15081 ssl_security_connector.cc:268] Handshaker factory creation failed with TSI_INVALID_ARGUMENT.
E0816 19:24:26.270775700 15081 server_secure_chttp2.cc:124] {"created":"#1629141866.270756657","description":"Unable to create secure server with credentials of type Ssl","file":"/opt/grpc_source/src/core/ext/transport/chttp2/server/secure/server_secure_chttp2.cc","file_line":104}
Segmentation fault
Running both the grpc c++ client and the grpc c++ server (on two different CentOS 7 boxes) in the "clear text" or "non secure" mode works perfectly fine - the said client happily packages its data into the protobuf message, executes the grpc call, the grpc c++ server receives the message and all is good.
Does anyone have any idea about what has to be done on the grpc c++ server side, I suspect, so that the functionality advertised on the grpc documentation site actually works - I am not looking to mess about with the custom certificate files, if it can be helped at all.
Using the default and built-in Ssl/Tls mechanism of the native grpc libraries is perfectly fine. In other words, some minimal viable grpc security is sufficient.
Thank you for any constructive insight.
I am following the ListFeatures() example in this tutorial: https://github.com/grpc/grpc/blob/v1.31.0/examples/cpp/route_guide/route_guide_client.cc
My server is in Java and my client application is in c++.
I have both the server and the client running locally. What I am observing is that my application crashes when I try to read the stream response via `reader->Read(&feature). I can verify that the server receives the api call and is sending responses back. I am also able to successfully hit the server from bloomRPC.
Any ideas why I can't receive responses in my c++ client application?
Much appreciated!
I had this problem when the context used to create the ClientReader fell out of scope. The context needs to be persistent while the ClientReader is in use.
I am doing this sample https://msdn.microsoft.com/en-us/library/windows/desktop/ms737889(v=vs.85).aspx that contains a C++ tutorial for client and server with Winsock. To run this the server must be run before the client, obviously, but how to debug these things. I mean when I start the server and put a breakpoint in the main function it executes, but when I do this in the client I want to see the interraction with the server code from its solution. Im confused. Is there an article describing this?