I wonder if there's a way to properly handle the situation when client can establish the channel to the server, but there's no matching service deployed on a server side.
So far in my tests I see that client can successfully send an rpc call and then wait forever for response.
Is there a way to instruct server or client to throw exception in this case?
I've stumbled upon the fallbackHandlerRegistry. But you can only return empty or null if nothing is found. There's seemingly no way you can say to the server close the call as there's nothing like this is deployed here.
No, there have logic to handle this situation, what is your language?
In grpc-java, it will check if the method is exist when execute StreamCreated task, and if method not found in registry and fallbackRegistry, it will return UNIMPLEMENTED status right now. You can reference the method StreamCreated#runInternal
The server does send UNIMPLEMENTED status in the response to the client and client will receive it as StatusRuntimeException with status = UNIMPLEMENTED
Related
I'm using the gremlin package version 3.5.2 with NodeJS.
If the server disconnects while the client waits for a query result from the server (await t.next()), the promise never finishes and the calling code gets stuck forever.
I've used the addListener function to register on "log" events and I see the client recognizes the socket was closed, but it doesn't throw an exception for ongoing requests.
I'm looking for a solution that will enable my server to handle such situations without getting stuck and without any resource leaks.
There is a ticket for it at: https://issues.apache.org/jira/browse/TINKERPOP-2754
You can find in the ticket a small program which demonstrates the problem.
A question related to the idempotence of serverside code, or the necessity of it. Either for gRPC in general, or specifically to the java implementation.
Is it possible that when we send a message once from a client, that it is handled twice by our service implementation?
Maybe this would be related to retries when service seems unavailable; or could be configured by some policy?
Right now, when you send a message from a client it will be seen (at most) once by the server. If you have idempotent methods, you will soon be able to specify a policy for automatic retries (design doc) but these retry attempts will not be enabled by default. You do not have to worry about the gRPC library sending your RPCs more than once unless you have this configured in your retry policy.
According to grpc-java/5724, the retry logic has already been implemented. The OP does it using a Map, that is not type safe. A better way would be as follows:
NettyChannelBuilder builder = NettyChannelBuilder.forAddress(host, port)
.enableRetry()
.maxRetryAttempts(3);
There are other retry configurations available on the NettyChannelBuilder.
There's also an example here, although it's pretty hard to find.
I am using java and google calendar API to insert/update/delete events from my google calendar. It is working fine.. At times it throws Connection Reset error when writing or updating the event via API.
Is there any possibility to resolve this issue.?
Thanks in advance..
If this is a java code, maybe the SO Posts below can help you determine what's wrong and where did you messed up in your code. Since I am not sure what code you are using, I'll give you an example where this error always occur.
SO post 1
"Exception in thread "main" java.net.SocketException: Connection
reset" error occurs when the opponent is forcibly terminated without
calling close().
Maybe there is something in your code that forced the opponent to be terminated without calling the close() function.
If that's the case, you can add this two line in both
Client
skt.close();
and ServerSock
ss.close();
Note: java.io.Closeable implementing object must call close ().
SO post 2
javadoc for SocketException states that
Thrown to indicate that there is an error in the underlying protocol
such as a TCP error
The connection in the server end maybe closed and caused the issue when sending the issue at their end.
To aid debugging you could look at using a tool such as Wireshark to
view the actual network packets. Also, is there an alternative client
to your Java code that you could use to test the web service? If this
was successful it could indicate a bug in the Java code.
As you are using Commons HTTP Client have a look at the Common HTTP
Client Logging Guide. This will tell you how to log the request at the
HTTP level.
Hope 1 of these two answers will help you.
In LivedataConnection, line 357, there's a comment that says:
// Sends the method message to the server. May be called additional times if
// we lose the connection and reconnect before receiving a result.
Does this mean that if a client calls a method and gets disconnected before the method returns, it will re-call that message when it reconnects? What if that method isn't idempotent?
Basically, yes, as of version 1.0. Meteor methods are not idempotent. I've reported this issue, as have others, and it's basically confirmed by a core developer:
https://github.com/meteor/meteor/issues/2407#issuecomment-52375372
The best way to fix this in most cases is to try and write a unique key to the database, associating with a method request, or to make use of some other clever conditional database updates. There are some discussions about how to do that in these threads:
https://groups.google.com/d/msg/meteor-talk/j1YF7JO5Rdo/cYHR5kbhC8UJ
https://stackoverflow.com/a/26430334/586086
I need to have a server which is able to call functions on the client. I always used RPC's in different networking game API's but I never implemented it by myself.
How would I do it?
My naive approach would be:
connect client to the server:
server
fn update_position_client(){
unique_id = 1;
send.to_client(unique_id);
}
client
while recv_messages {
if id == 1
update_position();
}
Is this how I would do it?
This works if you only have a few messages that you want to send, and if the data basically known. To be more robust, you would want to have the ability to dynamically add/remove messages that can be called, and figure out how to look up the methods to be called when RPC is called.
Assuming you want this to be completely transparent to the user, what typically happens in this case is that when the a message is sent, the RPC library will wait until there's a response back. Assuming bi-directional capabilities, what normally happens is that there's a single thread that listens for data. If an RPC message comes in, this thread will figure out what to do with the message, i.e. what method to call in your(local) address space and with what parameters you want to call it with. When you send an RPC message out, the thread that you sent the message out on is blocked(probably with a semaphore) until the return message comes back, at which point your local thread is unblocked and allowed to continue.
A Linux-specific RPC library you could look at would be DBus.