I've implemented an async server stream of messages and I have tests that call the rpc, then cause a message to be sent from the server, and then wait for the onNext().
Sometimes the tests fail because the rpc call arrives to the server after I cause a message. If I add a sleep of 300 millisecond on the server side, it fails consistently.
I've tried adding withWaitForReady() and it didn't help.
Is there a standard way to block an async stub until the method on the server side is finished?
Related
I'm writing a client which communicates with multiple server via gRPC. The data transfer works absolutely fine but I'm getting an exception on client side when one of the server stops abruptly. I would like to know if there is any error handling in gRPC library which can handle this server disconnection and do a clean exit from client side.
I can see methods like bool IsCancelled() const which could be used on server side to get status about client disconnection.
I need a similar method to be used on client to get notified about server disconnection.
I hope who ever is reading this is doing well.
Here's a scenario that I'm wondering about: there's a global ClientConn that is being used for all grpc requests to a server. Then that server goes down. I was wondering if there's a way to wait for this server to go up with some timeout in order for the usage of grpc in this scenario to be more resilient to failures(either a transient failure or server goes down). I was thinking keep looping if the clientConn state is connecting or a transient failure and if a timeout occurs when the clientConn state was a transient failure then return an error since the server might be down.
I was wondering if this would work if there are multiple requests coming in the client side that would need this ClientConn so then multiple go routines would be running this loop. Would appreciate any other alternatives, suggestions, or advice.
When you call grpc.Dial to connect to a server and receive a grpc.ClientConn, it will automatically handle reconnections for you. When you call a method or request a stream, it will fail if it can't connect to the server or if there is an error processing the request.
You could retry a few times if the error indicates that it is due to the network. You can check the grpc status codes in here https://github.com/grpc/grpc-go/blob/master/codes/codes.go#L31 and extract them from the returned error using status.FromError: https://pkg.go.dev/google.golang.org/grpc/status#FromError
You also have the grpc.WaitForReady option (https://pkg.go.dev/google.golang.org/grpc#WaitForReady) which can be used to block the grpc call until the server is ready if it is in a transient failure. In that case, you don't need to retry, but you should probably add a timeout that cancels the context to have control over how long you stay blocked.
If you want to even avoid trying to call the server, you could use ClientConn.WaitForStateChange (which is experimental) to detect any state change and call ClientConn.GetState to determine in what state is the connection to know when it is safe to start calling the server again.
I am starting with MassTransit and I have notice that when I call Send<T> in the ISendEndpoint it seems that the caller waits for the consumer to complete, is it an expected behavior? Since I am not using the mediator, shouldn't it just send the message to the endpoint and let the API (from which I am calling) free to process other requests?
Calling Send on a bus send endpoint does not wait for the consumer to complete. The returned Task is completed once the message has been acknowledged by the broker.
If you are using the request client, and calling GetResponse, that will wait for a response before completing the returned Task<TResponse>.
Using mediator, Send does wait.
I am writing a Server Client Program where omnet/veins is the client. However, omnet doesn't request data but acts on the data sent from the server. I want to keep listening for a message from the server but also allow other events to happen simultaneously without causing any delay in the execution of the events. I am using TraCIScenarioManager module to wait for the data from the server.
In an XPC service I'm developing, I would like to call xpc_connection_send_message_with_reply_sync or xpc_connection_send_message_with_reply from within the service's event handler (it requests some additional data from the client).
Instead of sending a message back to the client, it hangs. It seems like the message is waiting to be sent only after my event handler finishes.
Is there a way to communicate with the client without first retuning from the event handler?
Apparently it only hangs when sending a message to the same connection whose event handler my code is running in. When sending a message to a different connection it works fine.