Currently when an error occurs in a NodeJS server (eg: Buffer "out of bounds"), the entire server grinds to a halt. Is there a way to configure it such that only the socket on which the error occured gets disconnected leaving the server online and the other connections active? I could use the "uncaughtException" error but then there would be no way of knowing which socket caused the error/crashed. How is this handled typically?
You can use the try .. catch(err) construct to catch any exceptions occurring within any callback of the the socket, and subsequently socket.end(), to disconnect the client if an error occurs. This prevents the entire server from crashing. Obviously for the other "uncaught" errors you'll have to resort to the "uncaughtException" callback, which does not end the server. Why don't you read this and this for more answers.
Related
I am using the wrk HTTP benchmarking tool to test a server. And I am getting READ, WRITE as well as CONNECTION and TIMEOUT errors.
What I understand is:
CONNECTION errors, are caused by the refusal of a TCP connection.
Which could involve every element in the connection chain (Client,
ISP and Server).
TIMEOUT errors, are caused by the host failing to respond to a
request within a certain time.
But what about READ and WRITE errors?
I would really appreciate, if someone could point me in the direction of a good resource?
So what I understood from this code from the WRK repository is that.
WRITE ERROR’s happen when attempting to write on a connection, but it fails because of a closed socket on the server.
READ ERROR’s happen when attempting to read on a connection, but it fails because of a closed socket on the server.
Happy if anybody can confirm or refute that.
I am using a RMI/JRMP client/server employing spring-remoting. There are thousands of clients trying to connect and send requests. I have coded the server to refuse accepting a request when its plate is full than client can resend after waiting for some time. It works fine for most part, but for some strange reason it starts throwing below error intermittently for some clients and than starts working again for them when they keep retrying.
nested exception is org.springframework.remoting.RemoteLookupFailureException: Lookup of RMI stub failed;
nested exception is java.rmi.UnknownHostException: Unknown host: a.b.c.d;
I would appreciate if someone could throw some light on this, on causes and if there are ways to overcome this.
Thanks
I'm studying the following scenario: while get/set operations to Couchbase I shutting down node(power off on virtual machine). After that, I power on the machine and waiting for Couchbase node recovery. When node's status changing to "healthy" I expect that client reconnect and get/set operations continues. But sometimes reconnection of client occurs immediately, sometime doesn't occur within a few minutes.
So my question is:
Are there some configuration on server side, or on client side that guarantee a wholly reconnection of client?
I use JavaSDK.
A small addition:
Couchbase client is based on spymemcached client. If someone knows any hints with memcached, that could solve problem, I'll be very glad to see them.
Another addition:
Client stops trying to establish connection after this exception:
Exception in thread "Thread-122" java.lang.IllegalStateException: Got empty SASL auth mech list. 11:59:25,731 ERROR [stderr] (Thread-122) at net.spy.memcached.auth.AuthThread.listSupportedSASLMechanisms(AuthThread.java:99) 11:59:25,731 ERROR [stderr] (Thread-122) at net.spy.memcached.auth.AuthThread.run(AuthThread.java:112)
But I can't understand, why this exception happens so irregularly.
It's a small bug with response of CouchbaseServer. It's my discussion of this problem with developer of spymemcached client. Problem was solved when I hard-coded some string at this client.
My client app gets intermittent winsock errors (10060, 10053) against one particular server we interface with. I have it re-trying the request that failed, but sometimes it fails repeatedly, and I give up after 5 re-tries. Would it be likely to help at all if I closed the socket and created a new one? (I know nothing about the server-side.)
Ok, so the errors that you're getting are:
10060 - WSAETIMEDOUT
10053 - WSAECONNABORTED
When do you get them? What are you doing at the time?
You get a WSAECONNABORTED when the remote end of the connection, or possibly an intermediary router, resets the connection and sends an RST. This could simply be the remote end issuing a non lingering close or it could be the remote end aborting or crashing.
You can't continue doing anything with a connection that has had a WSAECONNABORTED on it as the connection has been aborted and is no more; it is a dead connection, it has passed on...
Context matters immensely as to why you might get a WSAETIMEDOUT exception and the context will dictate if retrying is sensible or not.
One thing I would try is- do tracert to your server.
Often when someone is connected through VPN; you may see this error because your local and remote ip addresses overlap.
e.g. if your local ipaddress range is 192.168.1.xxx and vpn remote range is also 192.168.1.xxx you will also see this error.
sharrajesh
What is the meaning of the "connection reset by peer" error on a TCP connection? Is it a fatal error or just a notification or related to the network failure?
It's fatal. The remote server has sent you a RST packet, which indicates an immediate dropping of the connection, rather than the usual handshake. This bypasses the normal half-closed state transition. I like this description:
"Connection reset by peer" is the TCP/IP equivalent of slamming the phone back on the hook. It's more polite than merely not replying, leaving one hanging. But it's not the FIN-ACK expected of the truly polite TCP/IP converseur.
This means that a TCP RST was received and the connection is now closed. This occurs when a packet is sent from your end of the connection but the other end does not recognize the connection; it will send back a packet with the RST bit set in order to forcibly close the connection.
This can happen if the other side crashes and then comes back up or if it calls close() on the socket while there is data from you in transit, and is an indication to you that some of the data that you previously sent may not have been received.
It is up to you whether that is an error; if the information you were sending was only for the benefit of the remote client then it may not matter that any final data may have been lost. However you should close the socket and free up any other resources associated with the connection.
one of the reasons for seeing this error and having trouble connecting to the server is that you enabled the firewall in the UNIX machine and forgot to add a rule to accept ssh connection. search in your WPS provider and you will find a way to connect to you machine and add this rules:
ufw allow ssh && ufw allow 22