Fire and forget for HTTP in Java
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
add a comment |
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
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
add a comment |
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
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
java httprequest httpclient analytics httpresponse
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
add a comment |
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
add a comment |
3 Answers
3
active
oldest
votes
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");
}
}
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
add a comment |
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.
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
add a comment |
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).
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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");
}
}
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
add a comment |
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");
}
}
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
add a comment |
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");
}
}
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");
}
}
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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).
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
add a comment |
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).
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
add a comment |
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).
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).
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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