Reputation: 56904
I am trying to use java.net.HttpURLConnection
to make a simple HTTP GET call and am running into something I can't explain:
public String makeGETCall(HttpURLConnection con) {
try {
System.out.println("About to make the request...");
if(con == null)
System.out.println("con is NULL");
else {
System.out.println("con is NOT null");
if(con.getInputStream() == null)
System.out.println("con's input stream is NULL");
else
System.out.println("con's input stream is NOT null");
}
} catch(Throwable t) {
System.out.println("Error: " + t.getMessage());
}
System.out.println("Returning...")
return "DUMMY DATA";
}
When I run this, I get the following console output:
About to make the request...
con is NOT null
And then the program terminates, without error. No exceptions get thrown, it doesn't exit unexpectedly, and it doesn't hang or timeout...it just dies.
It seems to be dying when I check con.getInputStream()
for being null
or not. But that still doesn't explain why it just dies quietly without any indication of error. Any ideas? I''m willing to admit that I could have created the HttpURLConnection
incorrectly, but still, there should be more indication of what is killing my program...Thanks in advance!
Upvotes: 4
Views: 1496
Reputation: 11
Fixed it.
con.setReadTimeout(1000)
obviously the HTTP Server accepts a connection, but is unable to fulfill the request when you connect in the wrong moment while server is starting. setReadTimeout causes the thread to throw an SocketTimeoutException.
Hope this helps someone else to solve the Problem...
As this Problem may also occur while using RESTlet with the internal connector, here is the solution for RESTlet. You have to take care of a hostnameVerifier and an SSLContextFactory by yourself:
context = new Context();
context.getParameters().add("readTimeout", Integer.toString(1000));
context.getAttributes().put("sslContextFactory", new YourSslContextFactory());
context.getAttributes().put("hostnameVerifier", new YourHostnameVerifier());
client = new Client(context, Protocol.HTTPS);
make sure
org.restlet.ext.ssl
org.restlet.ext.net
org.restlet.ext.httpclient
are in your classpath.
Best Regards
Upvotes: 0
Reputation: 11
same Problem here. I traced my code and it gets stuck at con.getInputStream() forever. To reproduce the Problem run the code example below. (put your correct URL)
A) Start any HTTPS Server on another Host
B) Start the Client Code
C) Shutdown HTTPS Server
D) Start HTTPS Server again
-> Stuck at con.getInputStream()
While restarting the HTTPS Server it seems like some deadlock in the client occurs. FYI I am using the bundle org.apache.felix.http.jetty as HTTP(S)-Server with a Restlet Servlet attached.
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.MalformedURLException;
import java.net.URL;
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSession;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
public class TestHTTPS{
public static void main(String[] args) throws InterruptedException
{
new TestHTTPS().activate();
}
private void activate() throws InterruptedException{
TrustManager[] insecureTrustManager = new TrustManager[] {
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
}
};
try {
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, insecureTrustManager, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (KeyManagementException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}
HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
};
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
String https_url = "https://192.168.xx.xx:8443";
URL url;
try {
url = new URL(https_url);
while(true) {
HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
con.setConnectTimeout(1000);
print_content(con);
Thread.sleep(100);
}
} catch (MalformedURLException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
private void print_content(HttpsURLConnection con){
if(con!=null){
try {
System.out.println("****** Content of the URL ********");
BufferedReader br =
new BufferedReader(
new InputStreamReader(con.getInputStream()));
String input;
while ((input = br.readLine()) != null){
System.out.println(input);
}
br.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
Any recommendations welcome.
Upvotes: 0
Reputation: 4514
Your code shouldn't be compiling since this line:
System.out.println("Returning...")
has a missing semi-colon. With that said, I would imagine any runs of the application you're using are using an old execution and don't have the new code you probably wrote.
If that's not the case then you've pasted your code incorrectly (somehow) and I would venture a guess that you missed other aspects that we need to see? If you've edited the code in some way for StackOverflow would you mind sharing the original?
Additionally, I would recommend against catching Throwable
unless you have good reason to. Its typically bad practice to mask application errors as such.
Upvotes: 1
Reputation: 718788
It seems to be dying when I check
con.getInputStream()
for being null or not.
Well I find that hard to believe.
On the face of it:
testing a reference to see if it is null
cannot terminate your program
the con.getInputStream()
can either throw an exception or return
if does return it shouldn't return null
... 'cos the API doesn't allow it ... and you would see a message
if an exception was thrown you would see the Error: ...
message
My conclusion is that a either different thread is causing the application to exit, or the application is not exiting at all.
The only other explanation I can think of is that your edit / compile / deploy / run procedure is not working, and the code that is actually being run doesn't match the code you are showing use.
I suggest that you attempt to create a SSCCE for this so that other people can reproduce it and figure out what is actually happening.
Upvotes: 0