I'm using a Java socket client. In a case where the server is still connected to my client but it does not send a response to my message - I eventually get a read time out exception.
In that case I want to test to see if I should reconnect my socket or just keep it an re-use it.
I use this condition:
if (!socket.isConnected() || socket.isClosed() || !socket.isBound()) {
try {
socket.close();
} catch (IOException e1) {
}
// Wait on a new connection
socket = connectSocket(.....);
}
But I always seem to reconnect. When I log the values of the Boolean properties I see this:
connected: true closed: true bound: true
How can it be connected and closed?
TIA
This thread has some useful discussions on this topic. It turns out that Socket.isConnected returns true if it has (ever) been successfully connected.
From the above thread:
When you use Socket(), which you seem to have overlooked,
Socket.isConnected() tells you whether Socket.connect() has been called
or not. Similarly for isClosed() and close().
Confusion over these methods results from confusing the state of the
socket, which is under the control of the application, with the state
of the overall connection, which is under the control of the protocol.
isConnected() and isClosed() tell what you have done to the socket.
There are no APIs other than read and write for determining the state of
the connection.
The docs says:
Returns true if the socket successfuly connected to a server
and not as one perhaps would expect "returns true if the socket is connected to a server".
The behavior can be confirmed by looking at the source of Socket:
public boolean isConnected() {
// Before 1.3 Sockets were always connected during creation
return connected || oldImpl;
}
You could also run this little test snippet:
Socket s = new Socket();
System.out.println("isConnected: " + s.isConnected() +
" isBound: " + s.isBound() +
" isClosed: " + s.isClosed());
s.connect(new InetSocketAddress("google.com", 80));
System.out.println("isConnected: " + s.isConnected() +
" isBound: " + s.isBound() +
" isClosed: " + s.isClosed());
s.close();
System.out.println("isConnected: " + s.isConnected() +
" isBound: " + s.isBound() +
" isClosed: " + s.isClosed());
Which prints:
isConnected: false isBound: false isClosed: false
isConnected: true isBound: true isClosed: false
isConnected: true isBound: true isClosed: true
I must say that the documentation is quite unclear on this point, and that the method-name is a bit misleading.
Related
I connect to external host successfully
void createConnection()
{
logger.info("Connecting to " + host_ + ":" + port_);
Socket sock_ = new Socket(host_, port_);
}
Connection is executed successfully, however I need to implement a reconnection mechanism, that is triggered when host is down/killed, and subsequently reconnect to A new host and port.
Is there such mechanism in JDK? Something like trigger event or Observer?
ManagedChannel managedChannel = ManagedChannelBuilder
.forAddress("localhost", 9090)
.usePlaintext().build();
System.out.println("State: " + managedChannel .getState(false)) // State: IDLE
Grpc.Stub stub = Grpc.newStub(managedChannel);
System.out.println("State: " + managedChannel .getState(false)) // State: IDLE
stub.callMethod();
System.out.println("State: " + managedChannel .getState(false)) // State: IDLE
Above code is GRPC client. It get connection with grpc server. But every time the channel state is IDLE? When is CONNECTING and READY state? Whats wrong?
It is required to wait for another state.
The following code prints connection state: TRANSIENT_FAILURE when server is not started and connection state: READY when it is healthy.
gRPC version: 1.24.0
ManagedChannel managedChannel = ManagedChannelBuilder
.forAddress("localhost", 9090)
.usePlaintext().build();
ConnectivityState state = channel.getState(true);
while (state == ConnectivityState.IDLE || state == ConnectivityState.CONNECTING) {
state = channel.getState(true);
}
System.out.println("connection state: " + state.toString());
I'm having a weird behavior with the isReachable method of InetAddress class.
Method prototype is :
public boolean isReachable(int timeout)
When using a timeout > 1500 (ms), the method waits the exact time
given as argument (if the target IP is not reachable of course...).
When using timeout < 1500, the method waits 1000ms maximum...
The code is quite simple :
InetAddress addr = null;
String ip = "10.48.2.169";
try {
addr = InetAddress.getByName(ip);
} catch (UnknownHostException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Timestamp s = new Timestamp(System.currentTimeMillis());
System.out.println(s + "\t Starting tests :");
pingTest(addr, 100);
pingTest(addr, 500);
pingTest(addr, 1000);
pingTest(addr, 1500);
pingTest(addr, 2000);
pingTest(addr, 2500);
Where pingTest is defined by :
public static void pingTest(InetAddress addr, int timeout) {
boolean result = false;
try {
result = addr.isReachable(timeout);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Timestamp s = new Timestamp(System.currentTimeMillis());
System.out.println(s + "\t (" + timeout + ") " + addr.toString() + " " + result);
}
Then the output is :
2017-09-07 16:45:41.573 Starting tests :
2017-09-07 16:45:42.542 (100) /10.48.2.169 false
2017-09-07 16:45:43.542 (500) /10.48.2.169 false
2017-09-07 16:45:44.541 (1000) /10.48.2.169 false
2017-09-07 16:45:46.041 (1500) /10.48.2.169 false
2017-09-07 16:45:48.041 (2000) /10.48.2.169 false
2017-09-07 16:45:50.541 (2500) /10.48.2.169 false
So the question is : Is there a minimum timeout to InetAddress isReachable method ? (like 1500 in my doubt, but I doubt, huge timeout...)
Or maybe I just made a huge mistake that I still miss...
Tell me if this isn't clear enough.
Thanks for your help and thoughts.
First you should notice that the behavior of INetAddress.isReachable is not the same on each platform supported by Java. I will assume you work on Windows.
When undocumented behavior happens you should always look at the source if they are available. The java.net implementation for windows is here for the OpenJDK (it should be quite similar for the Oracle JVM, but I am not sure of this).
What we saw in the isReachable method implementation is:
they don't rely on ping because they find the Windows ICMP protocol implementation too unreliable
they pass the timeout value to the NET_Wait function
So the isReachable method doesn't perform a ping and we need to check what the NET_Wait do with the timeout to understand why a less than 1 second timeout isn't possible.
The NET_Wait function is defined here: src/windows/native/java/net/net_util_md.c
It consist in an infinite loop which break when these events occurs during the select function call:
NET_WAIT_CONNECT on the socket file descriptor (socket is connected to the remote host)
The timeout ends
The select function is documented in a man page you may consult here. This man page tells us that the timeout can "be rounded up to the system clock granularity, and kernel scheduling delays mean that the blocking interval may overrun by a small amount".
This is why there is no guarantee on the minimal timeout value. Also, I think that the documentation doesn't state any minimal timeout value because the implementation differs on OSs supported by the JVM.
Hope this helps you understanding why.
However, to achieve a wanted timeout you may test the reachability in a separate task. You wait until the task returns the result, or if you wait more than your timeout you cancel the task or ignore its results.
I'm experiencing java.net.ConnectException in random ways.
My servlet runs in Tomcat 6.0 (JDK 1.6).
The servlet periodically fetches data from 4-5 third-party web servers.
The servlet uses a ScheduledExecutorService to fetch the data.
Run locally, all is fine and dandy. Run on my prod server, I see semi-random failures to fetch data from 1 of the third parties (Canadian weather data).
These are the URLs that are failing (plain RSS feeds):
http://weather.gc.ca/rss/city/pe-1_e.xml
http://weather.gc.ca/rss/city/pe-2_e.xml
http://weather.gc.ca/rss/city/pe-3_e.xml
http://weather.gc.ca/rss/city/pe-4_e.xml
http://weather.gc.ca/rss/city/pe-5_e.xml
http://weather.gc.ca/rss/city/pe-6_e.xml
http://meteo.gc.ca/rss/city/pe-1_f.xml
http://meteo.gc.ca/rss/city/pe-2_f.xml
http://meteo.gc.ca/rss/city/pe-3_f.xml
http://meteo.gc.ca/rss/city/pe-4_f.xml
http://meteo.gc.ca/rss/city/pe-5_f.xml
http://meteo.gc.ca/rss/city/pe-6_f.xml
Strange: each cycle, when I periodically fetch this data, the success/fail is all over the map: some succeed, some fail, but it never seems to be the same twice. So, I'm not completely blocked, just randomly blocked.
I slowed down my fetches, by introducing a 61s pause between each one. That had no effect.
The guts of the code that does the actual fetch:
private static final int TIMEOUT = 60*1000; //msecs
public String fetch(String aURL, String aEncoding /*UTF-8*/) {
String result = "";
long start = System.currentTimeMillis();
Scanner scanner = null;
URLConnection connection = null;
try {
URL url = new URL(aURL);
connection = url.openConnection(); //this doesn't talk to the network yet
connection.setConnectTimeout(TIMEOUT);
connection.setReadTimeout(TIMEOUT);
connection.connect(); //actually connects; this shouldn't be needed here
scanner = new Scanner(connection.getInputStream(), aEncoding);
scanner.useDelimiter(END_OF_INPUT);
result = scanner.next();
}
catch (IOException ex) {
long end = System.currentTimeMillis();
long time = end - start;
fLogger.severe(
"Problem connecting to " + aURL + " Encoding:" + aEncoding +
". Exception: " + ex.getMessage() + " " + ex.toString() + " Cause:" + ex.getCause() +
" Connection Timeout: " + connection.getConnectTimeout() + "msecs. Read timeout:" +
connection.getReadTimeout() + "msecs."
+ " Time taken to fail: " + time + " msecs."
);
}
finally {
if (scanner != null) scanner.close();
}
return result;
}
Example log entry showing a failure:
SEVERE: Problem connecting to http://weather.gc.ca/rss/city/pe-5_e.xml Encoding:UTF-8.
Exception: Connection timed out java.net.ConnectException: Connection timed out
Cause:null
Connection Timeout: 60000msecs.
Read timeout:60000msecs.
Time taken to fail: 15028 msecs.
Note that the time to fail is always 15s + a tiny amount.
Also note that it fails to reach the configured 60s timeout for the connection.
The host-server admins (Environment Canada) state that they don't have any kind of a blacklist for the IP address of misbehaving clients.
Also important: the code had been running for several months without this happening.
Someone suggested that instead I should use curl, a bash script, and cron. I implemented that, and it works fine.
I'm not able to solve this problem using Java.
This question already has an answer here:
Closed 12 years ago.
Possible Duplicate:
Why do the outputs differ when I run this code using NetBeans 6.8 and Eclipse?
When I am running the following code using Eclipse and NetBeans 6.8. I want to see the available COM ports on my computer. When running in Eclipse it is returning me all available COM ports, but when running it in NetBeans, it does not seem to find any ports ..
public static void test() {
Enumeration lists=CommPortIdentifier.getPortIdentifiers();
System.out.println(lists.hasMoreElements());
while (lists.hasMoreElements()) {
CommPortIdentifier cn =
(CommPortIdentifier)lists.nextElement();
if ((CommPortIdentifier.PORT_SERIAL==cn.getPortType())) {
System.out.println(
"Name is serail portzzzz " +
cn.getName()+
" Owned status " +
cn.isCurrentlyOwned());
try {
SerialPort port1=(SerialPort)cn.open("ComControl",800000);
port1.setSerialPortParams(
9600,
SerialPort.DATABITS_8,
SerialPort.STOPBITS_1,
SerialPort.PARITY_NONE);
System.out.println("Before get stream");
OutputStream out=port1.getOutputStream();
InputStream input=port1.getInputStream();
System.out.println("Before write");
out.write("AT".getBytes());
System.out.println("After write");
int sample=0;
//while((( sample=input.read())!=-1)){
System.out.println("Before read");
//System.out.println(input.read() + "TEsting ");
//}
System.out.println("After read");
System.out.println(
"Receive timeout is " +
port1.getReceiveTimeout());
}
catch(Exception e) {
System.err.println(e.getMessage());
}
}
else {
System.out.println(
"Name is parallel portzzzz " +
cn.getName() +
" Owned status " +
cn.isCurrentlyOwned() +
cn.getPortType() +
" ");
}
}
}
Output with Netbeans,
false
Output using Eclipse,
true
Name is serail portzzzz COM1 Owned status false
Before get stream
Before write
After write
Before read
After read
Receive timeout is -1
Name is serail portzzzz COM2 Owned status false
Before get stream
Before write
After write
Before read
After read
Receive timeout is -1
Name is parallel portzzzz LPT1 Owned status false2
Name is parallel portzzzz LPT2 Owned status false2
An initial guess would be that the library you use use native code enclosed in a DLL and that code cannot be found giving an error earlier you have missed, and the code falls back to a dummy behaviour.
I would have a closer look at the initialization code to see what happens there.