Fire and forget for HTTP in Java












2















We're implementing our own analytics for that we've exposed a web service which needs to be invoked which will capture the data in our DB.



The problem is that as this is analytics we would be making lot of calls (like for every page load, call after each js, CSS loads etc...) so there'll be many many such calls. So I don want the server to be loaded with lots of requests to be more precise pending for response. Because the response we get back will hardly be of any use to us.



So is there any way to just fire the web service request and forget that I've fired it?



I understand that every HTTP request will have as response as well.



So one thing that ticked my mind was what if we make the request timeout to zero second? But I'm pretty not sure if this is the right way of doing this.



Please provide me with more suggestions










share|improve this question























  • instead of making a call every time an event you want to record occurs, collect the event data and make fewer calls.

    – pvg
    Jul 9 '16 at 3:08











  • At some point you could consider UDP for this.

    – David Ehrmann
    Jul 9 '16 at 3:14
















2















We're implementing our own analytics for that we've exposed a web service which needs to be invoked which will capture the data in our DB.



The problem is that as this is analytics we would be making lot of calls (like for every page load, call after each js, CSS loads etc...) so there'll be many many such calls. So I don want the server to be loaded with lots of requests to be more precise pending for response. Because the response we get back will hardly be of any use to us.



So is there any way to just fire the web service request and forget that I've fired it?



I understand that every HTTP request will have as response as well.



So one thing that ticked my mind was what if we make the request timeout to zero second? But I'm pretty not sure if this is the right way of doing this.



Please provide me with more suggestions










share|improve this question























  • instead of making a call every time an event you want to record occurs, collect the event data and make fewer calls.

    – pvg
    Jul 9 '16 at 3:08











  • At some point you could consider UDP for this.

    – David Ehrmann
    Jul 9 '16 at 3:14














2












2








2








We're implementing our own analytics for that we've exposed a web service which needs to be invoked which will capture the data in our DB.



The problem is that as this is analytics we would be making lot of calls (like for every page load, call after each js, CSS loads etc...) so there'll be many many such calls. So I don want the server to be loaded with lots of requests to be more precise pending for response. Because the response we get back will hardly be of any use to us.



So is there any way to just fire the web service request and forget that I've fired it?



I understand that every HTTP request will have as response as well.



So one thing that ticked my mind was what if we make the request timeout to zero second? But I'm pretty not sure if this is the right way of doing this.



Please provide me with more suggestions










share|improve this question














We're implementing our own analytics for that we've exposed a web service which needs to be invoked which will capture the data in our DB.



The problem is that as this is analytics we would be making lot of calls (like for every page load, call after each js, CSS loads etc...) so there'll be many many such calls. So I don want the server to be loaded with lots of requests to be more precise pending for response. Because the response we get back will hardly be of any use to us.



So is there any way to just fire the web service request and forget that I've fired it?



I understand that every HTTP request will have as response as well.



So one thing that ticked my mind was what if we make the request timeout to zero second? But I'm pretty not sure if this is the right way of doing this.



Please provide me with more suggestions







java httprequest httpclient analytics httpresponse






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jul 9 '16 at 1:44









Gokul KulkarniGokul Kulkarni

54511024




54511024













  • instead of making a call every time an event you want to record occurs, collect the event data and make fewer calls.

    – pvg
    Jul 9 '16 at 3:08











  • At some point you could consider UDP for this.

    – David Ehrmann
    Jul 9 '16 at 3:14



















  • instead of making a call every time an event you want to record occurs, collect the event data and make fewer calls.

    – pvg
    Jul 9 '16 at 3:08











  • At some point you could consider UDP for this.

    – David Ehrmann
    Jul 9 '16 at 3:14

















instead of making a call every time an event you want to record occurs, collect the event data and make fewer calls.

– pvg
Jul 9 '16 at 3:08





instead of making a call every time an event you want to record occurs, collect the event data and make fewer calls.

– pvg
Jul 9 '16 at 3:08













At some point you could consider UDP for this.

– David Ehrmann
Jul 9 '16 at 3:14





At some point you could consider UDP for this.

– David Ehrmann
Jul 9 '16 at 3:14












3 Answers
3






active

oldest

votes


















2














You might find following AsyncRequestDemo.java useful:



import java.net.URI;
import java.net.URISyntaxException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import org.apache.http.client.fluent.Async;
import org.apache.http.client.fluent.Content;
import org.apache.http.client.fluent.Request;
import org.apache.http.client.utils.URIBuilder;
import org.apache.http.concurrent.FutureCallback;

/**
* Following libraries have been used:
*
* 1) httpcore-4.4.5.jar
* 2) httpclient-4.5.2.jar
* 3) commons-logging-1.2.jar
* 4) fluent-hc-4.5.2.jar *
*
*/

public class AsyncRequestDemo {
public static void main(String args) throws Exception {
URIBuilder urlBuilder = new URIBuilder()
.setScheme("http")
.setHost("stackoverflow.com")
.setPath("/questions/38277471/fire-and-forget-for-http-in-java");

final int nThreads = 3; // no. of threads in the pool
final int timeout = 0; // connection time out in milliseconds

URI uri = null;
try {
uri = urlBuilder.build();
} catch (URISyntaxException use) {
use.printStackTrace();
}

ExecutorService executorService = Executors.newFixedThreadPool(nThreads);
Async async = Async.newInstance().use(executorService);
final Request request = Request.Get(uri).connectTimeout(timeout);

Future<Content> future = async.execute(request, new FutureCallback<Content>() {
public void failed(final Exception e) {
System.out.println("Request failed: " + request);
System.exit(1);
}

public void completed(final Content content) {
System.out.println("Request completed: " + request);
System.out.println(content.asString());
System.exit(0);
}

public void cancelled() {
}
});

System.out.println("Request submitted");

}

}





share|improve this answer


























  • this solution is better than what I thought but, still there'll be still 12(or whatever threadpool size) threads. Problem here is we R using it for analytics so we need to serve lot of requests. Can we think of something else ? May be threadpool with some size n setting network time-out to zero?

    – Gokul Kulkarni
    Jul 10 '16 at 5:39











  • Hi @GokulKulkarni the two aspects i) threadpool with some size n and ii) network time-out have incorporated in the answer. Please have a look at it.

    – Sanjeev Saha
    Jul 10 '16 at 6:48



















1














I used this:



import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

URL url = new URL(YOUR_URL_PATH, "UTF-8"));
ExecutorService executor = Executors.newFixedThreadPool(1);
Future<HttpResponse> response = executor.submit(new HttpRequest(url));
executor.shutdown();


for HttpRequest,HttpResponse



public class HttpRequest implements Callable<HttpResponse> {
private URL url;

public HttpRequest(URL url) {
this.url = url;
}

@Override
public HttpResponse call() throws Exception {
return new HttpResponse(url.openStream());
}
}

public class HttpResponse {
private InputStream body;

public HttpResponse(InputStream body) {
this.body = body;
}

public InputStream getBody() {
return body;
}
}


that is.






share|improve this answer
























  • In this method we close the executor but I assume that the thread will still wait for the response as HTTP is designed to do that. Below are two links in order which will help understand the basics: 1. lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0061.html 2. systembash.com/a-simple-java-udp-server-and-udp-client

    – Mohit Angiras
    Nov 4 '17 at 8:01





















-1














Yes, you could initiate the request and break the connection without waiting for a response... But you probably don't want to do that. The overhead of the server-side having to deal with ungracefully broken connections will far outweigh letting it proceed with returning a response.



A better approach to solving this kind of performance problem in a Java servlet would bet to shove all the data from the requests into a queue, respond immediately, and have one or more worker threads pick up items out of the queue for processing (such as writing it into a database).






share|improve this answer



















  • 1





    'The overhead ... will far outweigh' why? How can not sending data over the wire be worse than sending data over the wire.

    – user207421
    Jul 9 '16 at 3:08











  • Because Java is going to throw an exception, generate a stack trace, etc... which will have to be handled. That gets expensive if the concern is performance. The connection/handshakes have already been established, so completing the response (even an empty one) is safer than breaking the connection. btw - I didn't say you couldn't do it. I said you probably don't want to.

    – Jason
    Jul 9 '16 at 3:12













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f38277471%2ffire-and-forget-for-http-in-java%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














You might find following AsyncRequestDemo.java useful:



import java.net.URI;
import java.net.URISyntaxException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import org.apache.http.client.fluent.Async;
import org.apache.http.client.fluent.Content;
import org.apache.http.client.fluent.Request;
import org.apache.http.client.utils.URIBuilder;
import org.apache.http.concurrent.FutureCallback;

/**
* Following libraries have been used:
*
* 1) httpcore-4.4.5.jar
* 2) httpclient-4.5.2.jar
* 3) commons-logging-1.2.jar
* 4) fluent-hc-4.5.2.jar *
*
*/

public class AsyncRequestDemo {
public static void main(String args) throws Exception {
URIBuilder urlBuilder = new URIBuilder()
.setScheme("http")
.setHost("stackoverflow.com")
.setPath("/questions/38277471/fire-and-forget-for-http-in-java");

final int nThreads = 3; // no. of threads in the pool
final int timeout = 0; // connection time out in milliseconds

URI uri = null;
try {
uri = urlBuilder.build();
} catch (URISyntaxException use) {
use.printStackTrace();
}

ExecutorService executorService = Executors.newFixedThreadPool(nThreads);
Async async = Async.newInstance().use(executorService);
final Request request = Request.Get(uri).connectTimeout(timeout);

Future<Content> future = async.execute(request, new FutureCallback<Content>() {
public void failed(final Exception e) {
System.out.println("Request failed: " + request);
System.exit(1);
}

public void completed(final Content content) {
System.out.println("Request completed: " + request);
System.out.println(content.asString());
System.exit(0);
}

public void cancelled() {
}
});

System.out.println("Request submitted");

}

}





share|improve this answer


























  • this solution is better than what I thought but, still there'll be still 12(or whatever threadpool size) threads. Problem here is we R using it for analytics so we need to serve lot of requests. Can we think of something else ? May be threadpool with some size n setting network time-out to zero?

    – Gokul Kulkarni
    Jul 10 '16 at 5:39











  • Hi @GokulKulkarni the two aspects i) threadpool with some size n and ii) network time-out have incorporated in the answer. Please have a look at it.

    – Sanjeev Saha
    Jul 10 '16 at 6:48
















2














You might find following AsyncRequestDemo.java useful:



import java.net.URI;
import java.net.URISyntaxException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import org.apache.http.client.fluent.Async;
import org.apache.http.client.fluent.Content;
import org.apache.http.client.fluent.Request;
import org.apache.http.client.utils.URIBuilder;
import org.apache.http.concurrent.FutureCallback;

/**
* Following libraries have been used:
*
* 1) httpcore-4.4.5.jar
* 2) httpclient-4.5.2.jar
* 3) commons-logging-1.2.jar
* 4) fluent-hc-4.5.2.jar *
*
*/

public class AsyncRequestDemo {
public static void main(String args) throws Exception {
URIBuilder urlBuilder = new URIBuilder()
.setScheme("http")
.setHost("stackoverflow.com")
.setPath("/questions/38277471/fire-and-forget-for-http-in-java");

final int nThreads = 3; // no. of threads in the pool
final int timeout = 0; // connection time out in milliseconds

URI uri = null;
try {
uri = urlBuilder.build();
} catch (URISyntaxException use) {
use.printStackTrace();
}

ExecutorService executorService = Executors.newFixedThreadPool(nThreads);
Async async = Async.newInstance().use(executorService);
final Request request = Request.Get(uri).connectTimeout(timeout);

Future<Content> future = async.execute(request, new FutureCallback<Content>() {
public void failed(final Exception e) {
System.out.println("Request failed: " + request);
System.exit(1);
}

public void completed(final Content content) {
System.out.println("Request completed: " + request);
System.out.println(content.asString());
System.exit(0);
}

public void cancelled() {
}
});

System.out.println("Request submitted");

}

}





share|improve this answer


























  • this solution is better than what I thought but, still there'll be still 12(or whatever threadpool size) threads. Problem here is we R using it for analytics so we need to serve lot of requests. Can we think of something else ? May be threadpool with some size n setting network time-out to zero?

    – Gokul Kulkarni
    Jul 10 '16 at 5:39











  • Hi @GokulKulkarni the two aspects i) threadpool with some size n and ii) network time-out have incorporated in the answer. Please have a look at it.

    – Sanjeev Saha
    Jul 10 '16 at 6:48














2












2








2







You might find following AsyncRequestDemo.java useful:



import java.net.URI;
import java.net.URISyntaxException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import org.apache.http.client.fluent.Async;
import org.apache.http.client.fluent.Content;
import org.apache.http.client.fluent.Request;
import org.apache.http.client.utils.URIBuilder;
import org.apache.http.concurrent.FutureCallback;

/**
* Following libraries have been used:
*
* 1) httpcore-4.4.5.jar
* 2) httpclient-4.5.2.jar
* 3) commons-logging-1.2.jar
* 4) fluent-hc-4.5.2.jar *
*
*/

public class AsyncRequestDemo {
public static void main(String args) throws Exception {
URIBuilder urlBuilder = new URIBuilder()
.setScheme("http")
.setHost("stackoverflow.com")
.setPath("/questions/38277471/fire-and-forget-for-http-in-java");

final int nThreads = 3; // no. of threads in the pool
final int timeout = 0; // connection time out in milliseconds

URI uri = null;
try {
uri = urlBuilder.build();
} catch (URISyntaxException use) {
use.printStackTrace();
}

ExecutorService executorService = Executors.newFixedThreadPool(nThreads);
Async async = Async.newInstance().use(executorService);
final Request request = Request.Get(uri).connectTimeout(timeout);

Future<Content> future = async.execute(request, new FutureCallback<Content>() {
public void failed(final Exception e) {
System.out.println("Request failed: " + request);
System.exit(1);
}

public void completed(final Content content) {
System.out.println("Request completed: " + request);
System.out.println(content.asString());
System.exit(0);
}

public void cancelled() {
}
});

System.out.println("Request submitted");

}

}





share|improve this answer















You might find following AsyncRequestDemo.java useful:



import java.net.URI;
import java.net.URISyntaxException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import org.apache.http.client.fluent.Async;
import org.apache.http.client.fluent.Content;
import org.apache.http.client.fluent.Request;
import org.apache.http.client.utils.URIBuilder;
import org.apache.http.concurrent.FutureCallback;

/**
* Following libraries have been used:
*
* 1) httpcore-4.4.5.jar
* 2) httpclient-4.5.2.jar
* 3) commons-logging-1.2.jar
* 4) fluent-hc-4.5.2.jar *
*
*/

public class AsyncRequestDemo {
public static void main(String args) throws Exception {
URIBuilder urlBuilder = new URIBuilder()
.setScheme("http")
.setHost("stackoverflow.com")
.setPath("/questions/38277471/fire-and-forget-for-http-in-java");

final int nThreads = 3; // no. of threads in the pool
final int timeout = 0; // connection time out in milliseconds

URI uri = null;
try {
uri = urlBuilder.build();
} catch (URISyntaxException use) {
use.printStackTrace();
}

ExecutorService executorService = Executors.newFixedThreadPool(nThreads);
Async async = Async.newInstance().use(executorService);
final Request request = Request.Get(uri).connectTimeout(timeout);

Future<Content> future = async.execute(request, new FutureCallback<Content>() {
public void failed(final Exception e) {
System.out.println("Request failed: " + request);
System.exit(1);
}

public void completed(final Content content) {
System.out.println("Request completed: " + request);
System.out.println(content.asString());
System.exit(0);
}

public void cancelled() {
}
});

System.out.println("Request submitted");

}

}






share|improve this answer














share|improve this answer



share|improve this answer








edited Jul 10 '16 at 16:10

























answered Jul 9 '16 at 3:03









Sanjeev SahaSanjeev Saha

2,2211514




2,2211514













  • this solution is better than what I thought but, still there'll be still 12(or whatever threadpool size) threads. Problem here is we R using it for analytics so we need to serve lot of requests. Can we think of something else ? May be threadpool with some size n setting network time-out to zero?

    – Gokul Kulkarni
    Jul 10 '16 at 5:39











  • Hi @GokulKulkarni the two aspects i) threadpool with some size n and ii) network time-out have incorporated in the answer. Please have a look at it.

    – Sanjeev Saha
    Jul 10 '16 at 6:48



















  • this solution is better than what I thought but, still there'll be still 12(or whatever threadpool size) threads. Problem here is we R using it for analytics so we need to serve lot of requests. Can we think of something else ? May be threadpool with some size n setting network time-out to zero?

    – Gokul Kulkarni
    Jul 10 '16 at 5:39











  • Hi @GokulKulkarni the two aspects i) threadpool with some size n and ii) network time-out have incorporated in the answer. Please have a look at it.

    – Sanjeev Saha
    Jul 10 '16 at 6:48

















this solution is better than what I thought but, still there'll be still 12(or whatever threadpool size) threads. Problem here is we R using it for analytics so we need to serve lot of requests. Can we think of something else ? May be threadpool with some size n setting network time-out to zero?

– Gokul Kulkarni
Jul 10 '16 at 5:39





this solution is better than what I thought but, still there'll be still 12(or whatever threadpool size) threads. Problem here is we R using it for analytics so we need to serve lot of requests. Can we think of something else ? May be threadpool with some size n setting network time-out to zero?

– Gokul Kulkarni
Jul 10 '16 at 5:39













Hi @GokulKulkarni the two aspects i) threadpool with some size n and ii) network time-out have incorporated in the answer. Please have a look at it.

– Sanjeev Saha
Jul 10 '16 at 6:48





Hi @GokulKulkarni the two aspects i) threadpool with some size n and ii) network time-out have incorporated in the answer. Please have a look at it.

– Sanjeev Saha
Jul 10 '16 at 6:48













1














I used this:



import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

URL url = new URL(YOUR_URL_PATH, "UTF-8"));
ExecutorService executor = Executors.newFixedThreadPool(1);
Future<HttpResponse> response = executor.submit(new HttpRequest(url));
executor.shutdown();


for HttpRequest,HttpResponse



public class HttpRequest implements Callable<HttpResponse> {
private URL url;

public HttpRequest(URL url) {
this.url = url;
}

@Override
public HttpResponse call() throws Exception {
return new HttpResponse(url.openStream());
}
}

public class HttpResponse {
private InputStream body;

public HttpResponse(InputStream body) {
this.body = body;
}

public InputStream getBody() {
return body;
}
}


that is.






share|improve this answer
























  • In this method we close the executor but I assume that the thread will still wait for the response as HTTP is designed to do that. Below are two links in order which will help understand the basics: 1. lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0061.html 2. systembash.com/a-simple-java-udp-server-and-udp-client

    – Mohit Angiras
    Nov 4 '17 at 8:01


















1














I used this:



import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

URL url = new URL(YOUR_URL_PATH, "UTF-8"));
ExecutorService executor = Executors.newFixedThreadPool(1);
Future<HttpResponse> response = executor.submit(new HttpRequest(url));
executor.shutdown();


for HttpRequest,HttpResponse



public class HttpRequest implements Callable<HttpResponse> {
private URL url;

public HttpRequest(URL url) {
this.url = url;
}

@Override
public HttpResponse call() throws Exception {
return new HttpResponse(url.openStream());
}
}

public class HttpResponse {
private InputStream body;

public HttpResponse(InputStream body) {
this.body = body;
}

public InputStream getBody() {
return body;
}
}


that is.






share|improve this answer
























  • In this method we close the executor but I assume that the thread will still wait for the response as HTTP is designed to do that. Below are two links in order which will help understand the basics: 1. lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0061.html 2. systembash.com/a-simple-java-udp-server-and-udp-client

    – Mohit Angiras
    Nov 4 '17 at 8:01
















1












1








1







I used this:



import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

URL url = new URL(YOUR_URL_PATH, "UTF-8"));
ExecutorService executor = Executors.newFixedThreadPool(1);
Future<HttpResponse> response = executor.submit(new HttpRequest(url));
executor.shutdown();


for HttpRequest,HttpResponse



public class HttpRequest implements Callable<HttpResponse> {
private URL url;

public HttpRequest(URL url) {
this.url = url;
}

@Override
public HttpResponse call() throws Exception {
return new HttpResponse(url.openStream());
}
}

public class HttpResponse {
private InputStream body;

public HttpResponse(InputStream body) {
this.body = body;
}

public InputStream getBody() {
return body;
}
}


that is.






share|improve this answer













I used this:



import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

URL url = new URL(YOUR_URL_PATH, "UTF-8"));
ExecutorService executor = Executors.newFixedThreadPool(1);
Future<HttpResponse> response = executor.submit(new HttpRequest(url));
executor.shutdown();


for HttpRequest,HttpResponse



public class HttpRequest implements Callable<HttpResponse> {
private URL url;

public HttpRequest(URL url) {
this.url = url;
}

@Override
public HttpResponse call() throws Exception {
return new HttpResponse(url.openStream());
}
}

public class HttpResponse {
private InputStream body;

public HttpResponse(InputStream body) {
this.body = body;
}

public InputStream getBody() {
return body;
}
}


that is.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jul 10 '16 at 6:48









IbrahimAsadIbrahimAsad

3711515




3711515













  • In this method we close the executor but I assume that the thread will still wait for the response as HTTP is designed to do that. Below are two links in order which will help understand the basics: 1. lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0061.html 2. systembash.com/a-simple-java-udp-server-and-udp-client

    – Mohit Angiras
    Nov 4 '17 at 8:01





















  • In this method we close the executor but I assume that the thread will still wait for the response as HTTP is designed to do that. Below are two links in order which will help understand the basics: 1. lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0061.html 2. systembash.com/a-simple-java-udp-server-and-udp-client

    – Mohit Angiras
    Nov 4 '17 at 8:01



















In this method we close the executor but I assume that the thread will still wait for the response as HTTP is designed to do that. Below are two links in order which will help understand the basics: 1. lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0061.html 2. systembash.com/a-simple-java-udp-server-and-udp-client

– Mohit Angiras
Nov 4 '17 at 8:01







In this method we close the executor but I assume that the thread will still wait for the response as HTTP is designed to do that. Below are two links in order which will help understand the basics: 1. lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0061.html 2. systembash.com/a-simple-java-udp-server-and-udp-client

– Mohit Angiras
Nov 4 '17 at 8:01













-1














Yes, you could initiate the request and break the connection without waiting for a response... But you probably don't want to do that. The overhead of the server-side having to deal with ungracefully broken connections will far outweigh letting it proceed with returning a response.



A better approach to solving this kind of performance problem in a Java servlet would bet to shove all the data from the requests into a queue, respond immediately, and have one or more worker threads pick up items out of the queue for processing (such as writing it into a database).






share|improve this answer



















  • 1





    'The overhead ... will far outweigh' why? How can not sending data over the wire be worse than sending data over the wire.

    – user207421
    Jul 9 '16 at 3:08











  • Because Java is going to throw an exception, generate a stack trace, etc... which will have to be handled. That gets expensive if the concern is performance. The connection/handshakes have already been established, so completing the response (even an empty one) is safer than breaking the connection. btw - I didn't say you couldn't do it. I said you probably don't want to.

    – Jason
    Jul 9 '16 at 3:12


















-1














Yes, you could initiate the request and break the connection without waiting for a response... But you probably don't want to do that. The overhead of the server-side having to deal with ungracefully broken connections will far outweigh letting it proceed with returning a response.



A better approach to solving this kind of performance problem in a Java servlet would bet to shove all the data from the requests into a queue, respond immediately, and have one or more worker threads pick up items out of the queue for processing (such as writing it into a database).






share|improve this answer



















  • 1





    'The overhead ... will far outweigh' why? How can not sending data over the wire be worse than sending data over the wire.

    – user207421
    Jul 9 '16 at 3:08











  • Because Java is going to throw an exception, generate a stack trace, etc... which will have to be handled. That gets expensive if the concern is performance. The connection/handshakes have already been established, so completing the response (even an empty one) is safer than breaking the connection. btw - I didn't say you couldn't do it. I said you probably don't want to.

    – Jason
    Jul 9 '16 at 3:12
















-1












-1








-1







Yes, you could initiate the request and break the connection without waiting for a response... But you probably don't want to do that. The overhead of the server-side having to deal with ungracefully broken connections will far outweigh letting it proceed with returning a response.



A better approach to solving this kind of performance problem in a Java servlet would bet to shove all the data from the requests into a queue, respond immediately, and have one or more worker threads pick up items out of the queue for processing (such as writing it into a database).






share|improve this answer













Yes, you could initiate the request and break the connection without waiting for a response... But you probably don't want to do that. The overhead of the server-side having to deal with ungracefully broken connections will far outweigh letting it proceed with returning a response.



A better approach to solving this kind of performance problem in a Java servlet would bet to shove all the data from the requests into a queue, respond immediately, and have one or more worker threads pick up items out of the queue for processing (such as writing it into a database).







share|improve this answer












share|improve this answer



share|improve this answer










answered Jul 9 '16 at 2:45









JasonJason

263




263








  • 1





    'The overhead ... will far outweigh' why? How can not sending data over the wire be worse than sending data over the wire.

    – user207421
    Jul 9 '16 at 3:08











  • Because Java is going to throw an exception, generate a stack trace, etc... which will have to be handled. That gets expensive if the concern is performance. The connection/handshakes have already been established, so completing the response (even an empty one) is safer than breaking the connection. btw - I didn't say you couldn't do it. I said you probably don't want to.

    – Jason
    Jul 9 '16 at 3:12
















  • 1





    'The overhead ... will far outweigh' why? How can not sending data over the wire be worse than sending data over the wire.

    – user207421
    Jul 9 '16 at 3:08











  • Because Java is going to throw an exception, generate a stack trace, etc... which will have to be handled. That gets expensive if the concern is performance. The connection/handshakes have already been established, so completing the response (even an empty one) is safer than breaking the connection. btw - I didn't say you couldn't do it. I said you probably don't want to.

    – Jason
    Jul 9 '16 at 3:12










1




1





'The overhead ... will far outweigh' why? How can not sending data over the wire be worse than sending data over the wire.

– user207421
Jul 9 '16 at 3:08





'The overhead ... will far outweigh' why? How can not sending data over the wire be worse than sending data over the wire.

– user207421
Jul 9 '16 at 3:08













Because Java is going to throw an exception, generate a stack trace, etc... which will have to be handled. That gets expensive if the concern is performance. The connection/handshakes have already been established, so completing the response (even an empty one) is safer than breaking the connection. btw - I didn't say you couldn't do it. I said you probably don't want to.

– Jason
Jul 9 '16 at 3:12







Because Java is going to throw an exception, generate a stack trace, etc... which will have to be handled. That gets expensive if the concern is performance. The connection/handshakes have already been established, so completing the response (even an empty one) is safer than breaking the connection. btw - I didn't say you couldn't do it. I said you probably don't want to.

– Jason
Jul 9 '16 at 3:12




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f38277471%2ffire-and-forget-for-http-in-java%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Guess what letter conforming each word

Port of Spain

Run scheduled task as local user group (not BUILTIN)