Today I had a problem searching songs on Deezer API. The server was blocking my requests.
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 195.244.30.137:80
What do I need to do so that it wouldn't happen again?
I solved my problem.
There was a internet problem in my side.
Sorry
Related
I am doing some load testing on a service run with Apache2 and my load testing tool has a default timeout of 30 seconds. When I run the tool for a minute with 1 request per second load, it reports that 40 succeeded with 200 OK response and 20 requests were cancelled because client timeout exceeded while awaiting headers.
Now, I was trying to spot this on the server side. I can't see the timeouts logged either in apache access logs or gunicorn access logs. Note that I am interested in connections that weren't accepted as well as that are accepted and times out.
I have some experience working on similar services on Windows. The http.sys error logs would show connection dropped errors and we would know if our server was dropping connections.
When a client times out, all the server knows is that the client has aborted the connection. In mod_log's config, the %X format specifier is used to log the status of the client connection after the request has completed, which is exactly what you want to know in this case.
Configure your logs to use %X, and look for the X character in the log lines.
Bonus: I even found the discussion about this feature in apache's dev forum, from 20 years ago
Update:
Regarding refused connections, these cannot be logged by apache. Connection refusal is done by the kernel, in the tcp stack, and not by apache. The closest solution including only apache that I can think of is keeping track of the amount of open connections (using mod_status). If it reaches the maximum you know you might be refusing connections. Otherwise, you'd need to set up some monitoring solution to track tcp resets sent by the kernel.
I am trying to connect to remote socket server and i get an error: "Socket connection failed for unknown reasons"
spent a lot of time, and I could not find a solution (
Please, helpe me/ thanks
My client dep:
socketcluster-client 9.0.2,
angularjs 1.5.7
You can try another system which has similar system, check ClusterWS
https://github.com/ClusterWS/ClusterWS
I had this exact same error and I was trying to connect to a third party external API that was providing data through websockets. If this is what you are trying to do, socketcluster may not work because it only enables connection with a socketcluster client and a socketcluster server regardless of whether they are in the same domain or different domain. Hope that helps
I have an application that uses Camel Netty4 component as a consumer endpoint which is configured as a TCP client (clientMode set to true) with the reconnect option enabled. The reconnect feature works well, the TCP client automatically reconnects to the remote server after a connection outage. Unfortunately it seems that this reconnect behavior runs indefinitely until the connection is established. Is there some way to set a limit to this reconnect feature, i.e. put a limit on how many reconnect attempts can be made before throwing a connection error?
Another question but this one is for the Netty4 component implemented as a producer that sends a payload to a remote server. Is there a way to configure the endpoint to enable the reconnect feature which would allow the TCP client to try establish a connection for a number of attempts before throwing a connection error?
In Camel 2.17-SNAPSHOT, there is no way to limit the amount of reconnection attempts. The reconnection is handled by ClientModeTCPNettyServerBootstrapFactory#scheduleReconnect. See here.
Currently it doesn't track the number of attempts, but it would be pretty simple to implement this functionality by adding a counter inside the anonymous Runnable.
Could you please open a ticket in the Camel JIRA?
Thanks!
I dont think limit for retry feature is avaialble at present for consumer, but you can specify the interval in which these retries can happen , the timeunit is in milliseconds.
We have a makeshift SOAP client written in C# connecting to a CXF service on a desktop from a windows mobile device. When this device is connected via ActiveSync, it creates a virtual adapter for the RNDIS connection. This virtual adapter assigns a gateway IP to the host, 169.254.2.2.
When we attempt to go through the connection with the hostname or the host's IP set as the address in the C# client, everything works perfectly. When we however set the IP to be the RNDIS gateway (169.254.2.2), the connection is periodically lost on the server side. The CXF service keeps trying to connect, and eventually succeeds, but this results in a massive slowdown of the connection. There are no errors reported in our logs on the mobile C# side, only on the CXF server.
Does anyone have any clues as to why this is happening? We need to assert that 169.254.2.2 cannot possibly be used as a valid endpoint before we rule it out.
Oh, and in case it helps, the C# client is granted the IP 169.254.2.1 through DHCP after the ActiveSync connection.
The first issue that comes to my head, especially once I saw that you are using DCHP, is that the lease time on the IP from the DHCP server is expiring and the CXF server is having to wait for the DCHP server to issue a new lease.
Try lengthening the DCHP lease if you know that the IP won't be changing and use a static IP if you are able. That will at least remove that point of failure.
I found out the cause of this, but I feel bad for answering because I doubt there was any way someone else could have guessed that this was the problem:
On our CXF server, we have a call to InetAddress.getHostName() which basically does a reverse DNS lookup on the request sent from the C# client.
When using the ActiveSync IP address, there was no entry in the DNS for 169.254.2.1 (of course), so the java class would hang until the method timed out (which took about 20 seconds before it would write a response to the C# client). At 20 seconds per request, this resulted in the massive slowdown and lost connection errors.
We fixed this by moving the call to an executor thread that force-finished after half a second. Because it was in another thread, the slowdown became nonexistent. Glad to have that over with!
we wrote in C++ a screen sharing application based on sending screenshots.
It works by establishing a TCP connection btw the server and client, where the server forwards every new screenshot received for a user through the connection, and this is popped-up by the client.
Now, we are trying to host this on google app engine, and therefore need 'servlet'-ize and 'sandbox' the server code, so to implement this forwarding through HTTP requests.
I immagine the following:
1. Post request with the screenshot as multiple-data form (apache uploads ..).
But now the server needs to contact the specified client (who is logged in) to send it/forward the screenshot.
I'm not sure how to 'initiate' such connection from the servlet to the client. The client doesn't run any servlet environment (of course).
I know HTTP 1.1 mantains a TCP connection, but it seems gapps won't let me use it.
1 approaches that comes to mind is to send a CONTINUE 100 to every logged in user at login, and respond with the screenshot once it arrives. Upon receival the client makes another request, and so on.
an alternative (insipired from setting the refresh header for a browser) would be to have the app pool on a regular basis (every 5 secs).
You're not going to be able to do this effectively on GAE.
Problem 1: All output is buffered until your handler returns.
Problem 2: Quotas & Limits:
Some features impose limits unrelated
to quotas to protect the stability of
the system. For example, when an
application is called to serve a web
request, it must issue a response
within 30 seconds. If the application
takes too long, the process is
terminated and the server returns an
error code to the user. The request
timeout is dynamic, and may be
shortened if a request handler reaches
its timeout frequently to conserve
resources.
Comet support is on the product roadmap, but to me your app still seems like a poor fit for a GAE application.
Long Polling is the concept used for such asynchronous communications between server and client.
In Long Polling, servlet keeps a map of client and associated messages. Key of Map being client id and value being list of messages to be sent to the client. When a client opens a connection with server (sends request to a servlet), the servlet checks the Map if there are any messages to be sent to it. If found, it sends the messages to the client exits from the method. On receiving messages, the client opens a new connection to the server. If the servlet does not find any messages for given client, it waits till the Map gets updated with messages for given client.
This is a late reply, I'm aware, but I believe that Google have an answer for this requirement: the Channel API.