Apart from a timeout, is it possible for a request to be received by the server but still a VolleyError be found on the client side?
Yes it is. Error code 307 for instance occurs when a resource is temporarily not available but available on a different url which the server returns. So in this case, the client side gets an error.
Related
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.
What can be the reasons that cause a socket.io session to be crashed and server returns invalid session or session is disconnected ?
There is a specific situation that causes these problems with the session. When a client fails to send the pings at the expected interval the server declares the client gone and deletes the session. If a client that falls into this situation later tries to send a ping or another request using the now invalidated session id it will receive one of these errors.
Another possible problem with the same outcome is when the client does send the pings at the correct intervals, but the server is blocked or too busy to process these pings in time.
So to summarize, if you think your clients are well behaved, I would look at potential blocking tasks in your server.
Ok, I'll illustrate my problem in this figure project's architecture .
In fact, I have a websocket between the react app and the rasa ( tool for creating chatbots) based on flask. bot response need to access to an external API to retrieve some data. Here where things go wrong. Sometimes, these requests take too long to return a response, and that's when websocket misbehave.
Suppose, UI is making calls to rest service and the server stops.
Does UI come to know about the server's state?
Does UI get any response back from the server?
What difference does it make if the rest call was POST or PUT?
When REST Api is stopped,the UI/Browser/Client will show "Could not get any response
There was an error connecting to " error, irrespective of request type: PUT /POST.
To answer your questions :
Does UI come to know about the server's state?
If Server stops, you will get an error like : error connecting server. Which can be traced to multiple rootcauses. One of them can be : Server has stopped.
In case of error, Server's state can be sent to client using various error codes like:
500 Internal Server Error The 500 status code, or Internal Server Error, means that server cannot process the request for an unknown reason. Here is list of status codes for REST APis: https://www.w3.org/Protocols/HTTP/HTRESP.html
Does UI get any response back from the server?
If server is stopped, UI/Client will receive no response.
What difference does it make if the rest call was POST or PUT?
If the server has stopped, it doesn't make any difference.
You can run this scenario using a browser and running any app/REST service in your local machine.
(For this test you need not have any REST application running in your local, as you only want to test when it is stopped)
For instance, if your REST application server is up and available at port 8080, you can send request to this server by sending request form your browser : http://localhost:8080
For testing with POST/PUT collections, you can use any API Development tools like : Postman.
Let's assue your REST Api , exposes following urls :
/myPostRequest POST
/myPutRequest PUT
When you hit these urls from POSTMAN you get the same response :
POST http://localhost:8080/myPostRequest :
Could not get any response
There was an error connecting to http://localhost:8080/transition-order.
PUT http://localhost:8080/myPutRequest :
Could not get any response
There was an error connecting to http://localhost:8080/transition-order.
Client(could be UI) and Server are two dumb applications. They do and say what they are told to.
So whenever a client tries to call a server on a socket and there is no server listening to it, there is no response returned to the client. The client can interpret it in whatever way it wants. Most of the browsers show <host> refused to connect.
But if a server is listening to a socket, it responds to the client whichever way it was programmed to do. The server sends an appropriate status code and expects that the client knows how to interpret it. A server can send any random number it wants... the catch is, the client must know how to interpret it. otherwise, it's just one-way communication.
In order to provide smooth client-server communication, section 10 of RFC 2616 defines various codes with specific meaning as shown here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
These status codes are the same for all the types of Http methods.
I found golang context is useful for canceling the processing of the server during a client-server request scope.
I can use http.Request.WithContext method to issue the http request with context, but if the client side is NOT using golang, is it possible to achieve that?
Thanks
I'm not 100% sure what you are asking, but using a context for sometime like a timeout is possible for both handling incoming requests and outbound requests.
For incoming requests you can use the context and send back a timeout http status code indicating that the server want able to process the request. It doesn't matter what the client sends you, you get to decide the timeout on your own with the server.
For outgoing requests you don't need the server to even know you have a timeout. You simply set a timeout and have your request just cancel if it doesn't get a response back in a set time. This means you likely won't get any response from the server because your code would cancel the outgoing request.
Now are you asking for an example of how to code on of these? Or just if both are possible?
I have inherited an application (internal to my company) that uses javascript running in Internet Explorer which makes Ajax calls to a Struts-based application running in WebLogic Server v10.
Certain server-side operations in the system are taking longer than 3 minutes. Users consistently noticed that the Ajax call returns 503 error at the 3 minute mark. My users can wait longer than 3 minutes, but 503 errors interrupt their work.
This application needs to be performance tuned, but we badly need a temporary workaround to extend how much time can occur before a 503 error is returned.
The current theory is that the 503 error is being raised by the IE XMLHttpRequest object. A team of supposed WebLogic experts poured over our code and WebLogic logs, and declared that there's no timeout occurring on the server side. But I have my doubts.
My question is, which piece of software is responsible for raising 503 error: the browser, the Ajax javascript, or the server? And can this timeout period be changed?
A 503 error is kind of a catch-all for a lot of different types of errors, usually on the server side. In your case it could be that the server is just rejecting the connection after a certain timeout, and responding back with a 503 to indicate that the server is overloaded or cannot process your request.
A lot of times with web services, a 503 will be returned when the server code throws an exception or error. If the server code doesn't properly handle the error, it will bubble up to the server, which will just respond back with a generic 503.
http://www.checkupdown.com/status/E503.html
Error code 5xx (alternate definition)
RFC 2616
503 is a server error. XMLHttpRequest will happily wait longer than 3 minutes. The first thing you should do is satisfy yourself of that by visiting the problem URL in telnet or netcat or similar and seeing the 503 with javascript out of the picture.
Then you can proceed to find the timeout on the server side.
Your web server has a request reply timeout which is being tripped by long-running service requests. It could be the WebLogic server or a proxy. It is certainly not the client.
Have you considered submitting an asynchronous HTTP request that will be responded to immediately, and then polling another location for the eventual results? Three minutes is about 170 seconds too long.
503 is most likely due to a timeout on the server. If you can tune your Apache server, read about the Timeout attribute that you can set in httpd.conf.
Look in the httpd/logs/error_log to see if timeouts are occurring.
Refer also to this answer: Mod cluster proxy timeout in apache error logs .