We have a system setup where we use Stophe to connect to ejabberd over
BOSH running through HA-Proxy. When our clients are idle, they seem to
be hitting the timeout (# 1.1 * 60 seconds), which aborts the
outstanding long-poll. The library then appears to make the next
long-poll using the same rid. ejabberd shows repeating RID and returns error.
Related
I have a client Server configuration with one connection, the server cannot process the requests received in parallel, it processes them in series, to overcome this problem, we developed a proxy server (installed between client and server) to receive request open connection with the server ==> send request server ==> send response to the client ==> close connection.
The problem we have is this, the response is sent divided on 2 part, we did a TCPDUMP on the port, we see that the request is sent devised on two part one with a length 1 and the second with à length 33
We don't know if it's a configuration on the server or on the network
Can some one help us ?
I have implemented an IMAP server and I am facing the following problem:
There are some mail clients (Apple) that close a connection after 60 seconds. When a COPY command is received with a large number of mails, this command takes longer than 60 seconds on the server side. After 60 seconds this mail client closes the connection (I have seen the FIN in the TCP stack) and when the server tries to reply with a SUCCESS, the client is already gone.
After some time the mail client sends the same command and the same thing happens again.
I already tried to send a tcp keepalive without success.
Has anyone an idea what to try next?
You should be able to send an untagged OK response at any time. This may work as a keep alive:
* OK Working on it...
I have a Vert.x app that gets HTTP requests as a Server and later down the road sends the data (HTTP request as well) as a Client to several other servers (more than one Client exits).
I see in the logs that sometimes I get io.vertx.core.VertxException: Connection was closed
but with no other info.
How can I know which connection was the one that was actually closed? I have more than one connections active.
I tried to add exceptionHandler to HttpServer and to HttpClientRequest, but they both were never called.
The io.vertx.core.VertxException: Connection was closed can be triggered for both client connections and server connections.
You'd get these errors on your HTTP client connection if the remote server closed the connection before completing the response, and you'd be able to capture them by setting the appropriate handlers on the client request (With Vert.x 4, you'd do something like ...send().onFailure(err -> /* handle the failure */) ), which I believe you already do.
You'd get these errors for the HTTP server connection if the remote client disconnects, either before your server completed the response, or - if the connection has keep-alive enabled (which is the default for HTTP/1.1 connections) - even after the response was sent.
In case the client closed the server connection before the response was fully sent, you should be able to capture and handle there errors in the HttpServer.exceptionHandler(), as I'm sure you already do.
In case the client closed the server connection after the response was fully sent, while it is in a keep-alive state, then there is no HttpServerRequest (or RoutingContext if you are using vertx-web, as you should) where the exception happens in, so Vert.x would just disregard the error (see here for the code).
So why do you still see those errors in the log? It could be various things because that exception is also used to handle EventBus connections and all kinds of internal network streams managed by Vert.x servers - and all without a stack trace (the actual exception instance being thrown is created statically here), so Vert.x kinds of sucks in that way.
My recommendation: make sure you attach error handlers to everything (pay attention to websocket connections or HTTP response streams, if you use them) and if you still get those errors in the logs - maybe you can just ignroe them as the commenter suggested.
From this URL HTTP Keep Alive connection timeouts it says Chrome 13 has at least a 300 second connection timeout. That is if a request to the same server is not made within that timeout the connection will be closed. It also says that every 45 seconds Chrome will send a TCP keep-alive packet until the 300 second timeout expires. This is to avoid NAT/firewall that start dropping connections earlier.
Is there any settings in Chrome that I can check to verify these values? Can anyone point me to any documentation on what the values are on the latest version of Chrome?
I am implementing a heartbeat endpoint/route using play 2.2.1 built with Scala 2.10.2 (running Java 1.7.0_45). When
the heartbeat endpoint is called, I want the controller to make http calls to localhost. If all of those
calls are ok, then the heartbeat endpoint will return an OK http response.
When I execute the following url from curl, I get the expected 200 response:
http://localhost:9000/oauth2/token. I am also able to telnet to localhost 9000.
I am also able to use WS successfully with an external URL:
WS.url("http://www.example.com").withHeaders("Content-Type" -> "application/json").get()
However, when I execute it from within my play app, I get a 500 tcp_error response.
WS.url("http://localhost:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
WS.url("http://127.0.0.1:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
WS.url("http://HostName:9000/oauth2/token").withHeaders("Content-Type" -> "application/json").get()
Here is the exact error message I receive:
Network Error (tcp_error)
A communication error occurred: "Connection refused"
The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
For assistance, contact your network support team.
Do I need to configure something to allow a play application to make calls to itself? Is this a network problem on
my box? If so, why do curl and telnet work? If a network issue, then it must be a jvm specific networking issue?
Could it be a security problem with play calling to itself? Not sure where to go next.