I'm opening an HttpUrlConnection and am setting the connection timeout using its inherited setConnectTimeout method, but for one particular URL I'm getting a gateway timeout (a 504). I don't mind getting a gateway timeout as such, but I do object to it taking far longer than the connection timeout that I've set!
Does setConnectTimeout have no impact upon the gateway timeout? I couldn't see another intuitively-named method that I could use.
Thanks in advance.
You should set read timeout by setReadTimeout. If you got a 504, it means that the connection is ok, but waiting too long to read something from it.
See more here: http://docs.oracle.com/javase/6/docs/api/java/net/URLConnection.html#setReadTimeout(int)
Related
I want to get streaming data from the server. Server sends data as a multipart/x-mixed-replace format, and it has Connection: close property. Connection: close means, it wants that client must be close the connection when receive the chunked data. Am I right?
Or, connection not closed because of data is streaming (server sends chunked data each time, I'm not send get request to the server at each time. Or is this done in the background?). So, connection is not closing at any time until I call the inputStream.close() method. Right?
Also, if server is down at any time, http url connection will be thrown the IOException. In this case, Must I call the disconnect() method of the http url connection? Or, should I call just inputStream.close()?
How can I close the HttpURLConnection safely at any time?
Connection: close means, it wants that client must be close the
connection when receive the chunked data. Am I right?
Not exactly. A Connection: close header in an HTTP message is informative, not prescriptive. It advises the receiver that the server intends to close the connection after sending the response (see RFC 7230, section 6.1). The user is not obligated to take specific action in response, but it may save itself some time by not attempting any further communication over that connection after receiving the HTTP payload. In practice, however, yes, after receiving the response, the client should close the application-layer connection on its end, too, for until it does, it will tie up associated system resources for no good reason.
But none of that is really your concern if you're working with an HttpURLConnection and / or the InputStream obtained from one. Per its documentation:
Each HttpURLConnection instance is used to make a single request but
the underlying network connection to the HTTP server may be
transparently shared by other instances. Calling the close() methods
on the InputStream or OutputStream of an HttpURLConnection after a
request may free network resources associated with this instance but
has no effect on any shared persistent connection. Calling the
disconnect() method may close the underlying socket if a persistent
connection is otherwise idle at that time.
That is, HttpURLConnection manages the details of persistent connections for you.
You continue,
Or, connection not closed because of data is streaming(server sends
chunked data each time, I'm not send get request to the server at each
time. Or is this done in the background?).
It seems that you simply mean that the server does not specify a content-length, and sends a response of indeterminate length over an extended period of time. In that case, the Connection header probably hasn't much practical relevance.
So, connection is not
closing at any time until I close the inputStream.close() method.
Right?
The server will not ordinarily close the connection at its end until it has sent the complete response. If, in principle, the response has unbounded length, then there is no reason to expect the server to initiate a connection closure from its end other than server shutdown or failure.
Also, if server is down at any time, http url connection will be
thrown the IOException.
Maybe. If the attempt to establish a connection in the first place fails, then you can expect an IOException of some flavor. If the server goes down while delivering the response then you might get an exception, but you might also just see the end of the stream.
In this case, Must I call the disconnect()
method of the http url connection? Or, should I call just
inputStream.close()?
You do not ever need to disconnect(), and if you do then it is merely advisory, as described in the docs quoted above. If you reach the end of the stream then you should indeed close it. If an IOException is thrown while you are reading the stream then it's probably best to attempt to close() the stream, but be prepared for that to fail, too, as the stream might be in an inconsistent state.
How can I close the http url connection safely at any time?
Once you've actually connected an HttpURLConnection instance to the underlying resource, closing its stream(s) should be enough to indicate that you're done with it. Before you've connected, you don't need to do anything at all.
client.close(); is not closing connection to end point immediately. netstat is showing that the connection is open for couple of seconds after client.close call is completed.
Is there a way to force close the connection immediately?
This probably is due to the settings of the SO_LINGER value that defines the time between the close() call and the real closing of the connection.
More info about this socket option can be found in this SO answer, in Java it is possible to set the value with Socket.setSOLinger().
I don't know if it is possible to set this value for Jersey, at least I cannot find something in org.glassfish.jersey.client.ClientProperties
I am trying to set the write timeout in Cassandra with the Java drive. SocketOptions allows me to set a read and connect timeout but not a write timeout.
Does anyone knows the way to do this without changing the cassandra.yaml?
thanks
Altober
The name is misleading, but SocketOptions.getReadTimeoutMillis() applies to all requests from the driver to cassandra. You can think of it as a client-level timeout. If a response hasn't been returned by a cassandra node in that period of time an OperationTimeoutException will be raised and another node will be tried. Refer to the javadoc link above for more nuanced information about when the exception is raised to the client. Generally, you will want this timeout to be greater than your timeouts in cassandra.yaml, which is why 12 seconds is the default.
If you want to effectively manage timeouts at the client level, you can control this on a per query basis by using executeAsync along with a timed get on the ResultSetFuture to give up on the request after a period of time, i.e.:
ResultSet result = session.executeAsync("your query").get(300, TimeUnit.MILLISECONDS);
This will throw a TimeoutException if the request hasn't been completed in 300 ms.
We are getting a java.net.SocketTimeoutException on server B when client A connects to server B. No idea why. The client is sending data to the server and the server then throws this exception. How would one troubleshoot this issue?
Note currently this has happened only once. Not sure if this is reproduceable. Attempting to setup the test again..
I had same problems, when my users used 3G or 2G network. It means, that you send request to server, and can't estabilish connection, because of weak internet signal. You can increase timeouts on your connection
URLConnection connection;
int timeout = 30 * 1000;
connection.setConnectTimeout(timeout);
connection.setReadTimeout(timeout);
But if you have weaaak weeeaaaak internet connection, timeouts does not help you.
I'm just created 1 testFunction in WebService (or you can use one of yours) for testing connection with server before calling another required functions, and if I get SockectTimeoutException calling this function - just report to user notification "Weak internet connection!".
No data arrived at the receiver within the timeout period. That's all it means. Debugging it means finding out why the data you think was sent wasn't sent. A missing flush() for example.
I'm using the IA92 Java implementation for MQTT, which allows me to connect to a MQTT broker. In order to establish the connection, I'm doing something like this:
// Create connection spec
String mqttConnSpec = "tcp://the_server#the_port";
// Create the client and connect
mqttClient = MqttClient.createMqttClient(mqttConnSpec, null);
mqttClient.connect("the_id", true, 666);
The problem is that sometimes the server takes too much time to send a response, and it throws a timeout exception:
org.apache.harmony.luni.platform.OSNetworkSystem.connectStreamWithTimeoutSocket(OSNetworkSystem.java:130)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(PlainSocketImpl.java:246)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(PlainSocketImpl.java:533)
at java.net.Socket.connect(Socket.java:1055)
at com.ibm.mqtt.j2se.MqttJava14NetSocket.<init>((null):-1)
at com.ibm.mqtt.j2se.MqttJavaNetSocket.setConnection((null):-1)
at com.ibm.mqtt.Mqtt.tcpipConnect((null):-1)
at com.ibm.mqtt.MqttBaseClient.doConnect((null):-1)
at com.ibm.mqtt.MqttBaseClient.connect((null):-1)
at com.ibm.mqtt.MqttClient.connect((null):-1)
at com.ibm.mqtt.MqttClient.connect((null):-1)
What I need to do is setting a timeout manually, instead of letting the mqtt client decide that. The documentation says: There are also methods for setting attributes of the MQ Telemetry Transport connection, such as timeouts and retries.
But, honestly, I haven't found anything about it. I have taken a look at the whole javadoc reference and there's no evidence of timeout configuration. I can't see the source code since it's not open source.
So how can I set the timeout for the Mqtt connection?
If you have confusion you can go to MqttConnectionOptions for detail.
String userName="Ohelig";
String password="Pojke";
MqttClient client = new MqttClient("tcp://192.168.1.4:1883","Sending");
MqttConnectOptions authen = new MqttConnectOptions();
authen.setUserName(userName);
authen.setPassword(password.toCharArray());
authen.setKeepAliveInterval(30);
authen.setConnectionTimeout(300);
client.connect(authen);
I don't know anything about ia92, but I'd imagine that the 666 in the connect() call is what you're trying to set the timeout to?
The timeout the documentation is referring to is probably the keepalive timeout. This is the maximum number of seconds (chosen by the client) that can elapse without communication between the server and client. I think this is what you're most interested in.
Retries on the other hand are most likely to refer to the retrying of messages that seem to have gone astray when sending messages with QoS>0. This will be something handled by the client library code though, rather than the broker. This is something that comes into play only after you've connected though, so I very much doubt it's your problem.
To be sure that the keepalive timeout is being set correctly, I'd try pointing your client at a modified mosquitto broker. You can modify mqtt3_handle_connect() in src/read_handle_server.c to print out the keepalive value when you connect. This will ensure it's doing what you think, but won't help with the actual problem I'm afraid!
What broker do you use? Really Small Message Broker V1.1 Alpha, Mosquitto, the broker that comes with IBM WebSphere? You need to set this timeout value in your server configuration. Because the system works that way. You set a keep alive value in your broker and send a ping from the client before that interval expires, in order not for the broker to close the client-server connection, and the process restarts. Actually, even if that interval expires, server will still not close the connection until the 'grace period' ends. See http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#connect