I need to build a Java server where the client sends an HTTP request, the server sends an HTTP response, the client sends another HTTP request, and the server sends a final response. However, after the server sends the first response to the request, the connection times out. I realized that the client isn't even reading my response until I close the input stream, but this ends the conversation prematurely. Here is the run method for my class ServerThread, which extends Thread.
public void run() {
try {
l.add(index, serv.accept());
new ServerThread(serv, l, index + 1).start();
Socket socket = (Socket)l.get(index);
index++;
while(true) {
while(socket.getInputStream().available() == 0) {}
while(socket.getInputStream().available() > 0)
System.out.print((char)socket.getInputStream().read());
BufferedWriter b = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
b.write("HTTP/1.1 200 OK\n" +
"Connection: keep-alive");
b.flush();
//b.close();
}
} catch (IOException e) {
}
}
Basically, this code accepts a client and blocks until there is information in the input stream. After there is information, it prints out the request and writes a 200 OK response to the client regardless of the request and keep the connection alive. When I comment out the b.close() call, the conversation hangs, but as soon as I stop the server, the client reads the response. How do I get around this?
Related
I am trying to understand the Bayeux protocol. I haven't found a web-resource explaining how the bayeux client will technically work, in detail.
From this resource,
The Bayeux protocol requires that the first message a new client sends
be a handshake message (a message sent on /meta/handshake channel).
The client processes the handshake reply, and if it is successful,
starts – under the covers – a heartbeat mechanism with the server, by
exchanging connect messages (a message sent on a /meta/connect
channel).
The details of this heartbeat mechanism depend on the client
transport used, but can be seen as the client sending a connect
message and expecting a reply after some time.
Connect messages continue to flow between client and server until
either side decides to disconnect by sending a disconnect message (a
message sent on the /meta/disconnect channel).
I have written in Java methods to first do a handshake, then subscribe to a particular channel. I made use of the Apache HttpClient library to do the HTTP POST requests.
Now comes the part of connect.
My understanding is that, I need to keep a request open to the bayeux server and whenever I receive a response, make another request.
I have the written the below code. Is my understanding correct and does this bayeux client exhibit the correct connect functionality? (please ignore the missing disconnect, unsubscribe methods)
Also, I have tested the code against a bayeux server and it works correctly.
/* clientId - Unique clientId returned by bayeux server during handshake
responseHandler - see interface below */
private static void connect(String clientId, ResponseHandler responseHandler)
throws ClientProtocolException, UnsupportedEncodingException, IOException {
String message = "[{\"channel\":\"/meta/connect\","
+ "\"clientId\":\"" + clientId + "\"}]";
CloseableHttpClient httpClient = HttpClients.createDefault();
Thread t = new Thread(new Runnable() {
#Override
public void run() {
while (!doDisconnect) {
try {
CloseableHttpResponse response = HttpPostHelper.postToURL(ConfigurationMock.urlRealTime,
message, httpClient, ConfigurationMock.getAuthorizationHeader());
responseHandler.handleResponse(response);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
try {
httpClient.close();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
t.start();
}
/*Simple interface to define what happens with the response when it arrives*/
private interface ResponseHandler {
void handleResponse(CloseableHttpResponse httpResponse);
}
public static void main(String[] args) throws Exception{
String globalClientId = doHandShake(); //assume this method exists
subscribe(globalClientId,"/measurements/10500"); //assume this method exists
connect(globalClientId, new ResponseHandler() {
#Override
public void handleResponse(CloseableHttpResponse httpResponse) {
try {
System.out.println(HttpPostHelper.toStringResponse(httpResponse));
} catch (ParseException | IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
}
Your code is not correct.
Messages on the /meta/connect channel do not have the subscription field.
Subscriptions must be sent on the /meta/subscribe channel.
You want to study the Bayeux Specification for further details, in particular the meta messages section and the event messages section.
A suggestion is to launch the CometD Demo and look at the messages exchanged by the client, and mimic those in your implementation.
How can i get data immediantly from client in server netty 4.
In moment when i sending data to client ,client send me data.But handler (method channelRead())received data only after server sended a data
The problem i will show in a process list, i use netty 4:
get data from client
start calculate response
send some service data to client as (ctx.writeAndFlush()) (ok)
continue calculate response
should get data from client (here a problem)
send calculated response to client(sends ok).
My Code:
Handler
#Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
logger.debug("Start read handler " + ctx.channel().toString());
ByteBuf b = (ByteBuf) msg;
ctx.write(Unpooled.copiedBuffer( new Test.send(ctx,b) );
}
Test
public class Test
public byte[] send(ChannelHandlerContext ctx,ByteBuf b){
// start calculates
ctx.writeAndFlush(Unpooled.copiedBuffer(some data)); - its ok
// calculates .. (during here i should get data from client but nothing happens. Why does the channel blocks receiving data ? )
return response;
}
You should have an ChannelInboundHandler which will be notified once the response was received. Remember everything in netty is non-blocking.
I am trying my hand at using http.core & client 4.3. In general it works well, and is quite pleasant to deal with. However, I am getting a ConnectionClosedException on one of my transfers and I can't see why. Others work just fine as far as I can tell.
Everything follows the examples in a pretty straight forward way. If it didn't, it was re-written to as much as possible in an effort to get rid of this.
There are 2 servers, both running the same code [A & B]
A HttpClient sends a request "AX" (POST) to B
B HttpService receives the "AX" post, processes it
B HttpClient sends a reply "BR" (POST) to A on a different port
Later This should happen after the connection to A is closed, or as close as possible
Right now the code doesn't actually care
A receives the reply from B (on a different thread) and does things
In the problem scenario, A is running as the server, and B is sending a POST. Sorry it isn't always clear, since in one transaction both sides end up running server and client code.
A Sends POST to B:8080. Get back a proper response inline, everything ok.
POST Connection to B:8080 gets closed properly
B sends new POST (like an ACK) to A (ex... B:53991 => A:9000).
A Processs everything. No issues
A rasies ConnectionClosedException
Since I don't why it's happening for sure, I tried to put everything I think is relevant in there. My only thought right now is that it has something to with making sure I add/change connection control headers, but I can't see how that would affect anything.
Stack Trace from machine "A", when the reply from B comes
org.apache.http.ConnectionClosedException: Client closed connection
at org.apache.http.impl.io.DefaultHttpRequestParser.parseHead(DefaultHttpRequestParser.java:133)
at org.apache.http.impl.io.DefaultHttpRequestParser.parseHead(DefaultHttpRequestParser.java:54)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
at org.apache.http.impl.DefaultBHttpServerConnection.receiveRequestHeader(DefaultBHttpServerConnection.java:131)
at org.apache.http.protocol.HttpService.handleRequest(HttpService.java:307)
at com.me.HttpRequestHandlerThread.processConnection(HttpRequestHandlerThread.java:45)
at com.me.net.http.HttpRequestHandlerThread.run(HttpRequestHandlerThread.java:70)
com.me.ExceptionHolder: Client closed connection
at com.me.log.Log.logIdiocy(Log.java:77)
at com.me.log.Log.error(Log.java:54)
at com.me.net.http.HttpRequestHandlerThread.run(HttpRequestHandlerThread.java:72)
Caused by: org.apache.http.ConnectionClosedException: Client closed connection
at org.apache.http.impl.io.DefaultHttpRequestParser.parseHead(DefaultHttpRequestParser.java:133)
at org.apache.http.impl.io.DefaultHttpRequestParser.parseHead(DefaultHttpRequestParser.java:54)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
at org.apache.http.impl.DefaultBHttpServerConnection.receiveRequestHeader(DefaultBHttpServerConnection.java:131)
at org.apache.http.protocol.HttpService.handleRequest(HttpService.java:307)
at com.me.net.http.HttpRequestHandlerThread.processConnection(HttpRequestHandlerThread.java:45)
at com.me.net.http.HttpRequestHandlerThread.run(HttpRequestHandlerThread.java:70)
This is the code running on B, the "client" in this scenario. It is trying to POST the reply acknowledging that the first POST from A was received properly. There really isn't much to transmit, and the response should only be an HTTP 200:
try (CloseableHttpClient client = HttpClients.createDefault()) {
final HttpPost post = new HttpPost(url);
post.setHeaders(/* create application specific headers */);
ByteArrayEntity entity = new ByteArrayEntity(IOUtils.toByteArray(myStream));
post.setEntity(entity);
ResponseHandler<Void> responseHandler = new ResponseHandler<Void>() {
#Override
public Void handleResponse(HttpResponse response) throws ClientProtocolException, IOException {
StatusLine status = response.getStatusLine();
if (!NetUtil.isValidResponseCode(response)) {
throw new ClientProtocolException("Unexpected Error! Oops");
}
// consume the response, if there is one, so the connection will close properly
EntityUtils.consumeQuietly(response.getEntity());
return null;
}
};
try {
client.execute(post, responseHandler);
} catch (ClientProtocolException ex) {
// logic to queue a resend for 10 minutes later. not triggered
throw ex;
}
}
On A: This is called async because the response doesn't come in over the same http connection.
The main request handler does a lot more work, but it is amazing how little code there is actually controlling the HTTP in the handler/server side. Great library... that I am misusing somehow. This is the actual handler, with everything simplified a bit, validation removed, etc.
public class AsyncReceiverHandler implements HttpRequestHandler {
#Override
public void handle(HttpRequest request, HttpResponse response, HttpContext context) throws HttpException, IOException {
// error if not post, other logic. not touching http. no errors
DefaultBHttpServerConnection connection = (DefaultBHttpServerConnection) context.getAttribute("connection");
Package pkg = NetUtil.createPackageFrom(connection); // just reads sender ip/port
NetUtil.copyHttpHeaders(request, pkg);
try {
switch (recieive(request, pkg)) {
case EH_OK:
response.setStatusCode(HttpStatus.SC_OK);
break;
case OHNOES_BAD_INPUT:
response.setStatusCode(HttpStatus.SC_BAD_REQUEST);
response.setEntity(new StringEntity("No MDN entity found in request body"));
// bunch of other cases, but are not triggered. xfer was a-ok
}
} catch (Exception ex) {
//log
}
}
private MyStatus receiveMdn(HttpRequest request, Package pkg) throws Exceptions..., IOException {
// validate request, get entity, make package, no issues
HttpEntity resEntity = ((HttpEntityEnclosingRequest) request).getEntity();
try {
byte[] data = EntityUtils.toByteArray(resEntity);
// package processing logic, validation, fairly quick, no errors thrown
} catch (Exceptions... ex) {
throw ExceptionHolder(ex);
}
}
}
This is the request handler thread. This and the server are taken pretty much verbatim from the samples. The service handler just starts the service and accept()s the socket. When it gets one, it creates a new copy of this, and calls start():
public HttpRequestHandlerThread(final HttpService httpService, final HttpServerConnection conn, HttpReceiverModule ownerModule) {
super();
this.httpService = httpService;
this.conn = (DefaultBHttpServerConnection) conn;
}
private void processConnection() throws IOException, HttpException {
while (!Thread.interrupted() && this.conn.isOpen()) {
/* have the service create a handler and pass it the processed request/response/context */
HttpContext context = new BasicHttpContext(null);
this.httpService.handleRequest(this.conn, context);
}
}
#Override
public void run() {
// just runs the main logic and reports exceptions.
try {
processConnection();
} catch (ConnectionClosedException ignored) {
// logs error here (and others).
} finally {
try { this.conn.shutdown(); } catch (IOException ignored) {}
}
}
}
Well, this seems stupid now, and really obvious. I ignored the issue for a while and moved on to other things, and the answer bubbled up from the subconscious, as they will.
I added this header back and it all cleared up:
post.setHeader("Connection", "close, TE")
Somehow the line to set the Connection header got removed, probably accidentally by me. A lot of them get set, and it was still there, just wrong in this code path. Basically, the server expects this connection to close immediately but the header was reverting to the default keep-alive. Since the client closes the connection as soon as it is done with it this was surprising the server, who was told otherwise, and rightly compliained :D In the reverse path everything was OK.
Since I had just changed the old stack to use HttpComponents I didn't look at headers and such, and I just assumed I was using it wrong. The old stack didn't mind it.
Assume this scenario: I send a request to my server(apache tomcat) from a browser(firefox). The response come after about 2 minutes from server. How can I cancel this request in a way that my server do not continue for making the response ?
When a user sent a request to the server, it is common to go to another link(or menu or cancel the request) of application and it is so important for developers to cancel such these cases and so reduce the server load.
OK then, I want a technique to detect such incoming requests which are sent to my server and cancel all actions for making the response for client( because the client is not waiting for server response anymore).
I couldn't find useful information in google and stack.
I also set keep-alive-timeout in my server.xml, but nothing happened!
I also read this topic cancle request , but it didn't help me.
So please help me to solve this issue ...
You can cancel the request sending content to its outputstream (and flushing it).
If a user cancels the request, the servlet will loss the connection to the browser and then, sending content to the outputstream will throw a ClientAbortException making the process stop.
Try this:
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
ServletOutputStream out = response.getOutputStream();
try {
out.println("<!DOCTYPE html>");
out.println("<html><body>");
out.println("<h1 id=\"count\"></h1>");
for (int i = 0; i < 60; i++) {
Thread.sleep(1000);
out.print("<script>document.getElementById(\"count\").innerHTML=\"" + i + "\";</script>");
out.flush();
System.out.println(i);
}
out.println("</body></html>");
} catch (Exception ex) {
System.out.println("Stoped due to " + ex.toString());
} finally {
out.close();
}
}
I am facing quite an unusual situation.
I have two Jboss (7.1) instances which communicate via HTTP.
Instance A opens an HTTP connection to instance B and sends some data to be processed. The connection has timeout set, so after N seconds if no response is read it throws SocketTimeoutEception. Some cleanup is performed and the connection is closed.
Instance B has a servlet, listening for such http requests and when one is received some computation is done. After that the response is populated and returned to the client.
The problem is that if the computation takes too much time, the client (A) will close the connection due to the time out, but server (B) will proceed as normal and will try to send the response after some time. I want to be able to detect that the connection is closed and do some house keeping, however I can't seem to be able to do that.
I have tried calling HttpServletResponse.flushBuffer(), but no exception is thrown. I have also explicitly set in the http request "Connection: close" to avoid persistent connection, but this had no effect. The http servlet resonse is processed as normal and disappears in the void without any exception. I do not know what I am doing wrong, I've read other questions on this site like:
Java's HttpServletResponse doesn't have isClientConnected method
Tomcat - Servlet response blocking - problems with flush
but they do not work in my case.
I think there might be something specific to the jboss servlet container, which causes to ignore or buffer the response, or perhaps the http connection is reused despite my efforts to close it from the client (A). I'd be happy if you could provide some pointers to where to look for the problem. I have spend several days on this and no relevant progress was made, so I need to resolve this urgently.
Here is the relevant code:
Client code (server A):
private static int postContent(URL destination, String fileName, InputStream content)
throws IOException, CRPostException
{
HttpURLConnection connection = null;
//Create the connection object
connection = (HttpURLConnection)destination.openConnection();
// Prepare the HTTP headers
connection.setDoOutput(true);
connection.setInstanceFollowRedirects(false);
connection.setRequestMethod("POST");
connection.setRequestProperty("content-type", "text/xml; charset=UTF-8");
connection.setRequestProperty("Content-Encoding", "zip");
connection.setRequestProperty("Connection", "close");//Try to make it non-persistent
//Timouts
connection.setConnectTimeout(20000);//20 sec timout
connection.setReadTimeout(20000);//20 sec read timeout
// Connect to the remote system
connection.connect();
try
{
//Write something to the output stream
writeContent(connection, fileName, content);
//Handle response from server
return handleResponse(connection);
}
finally
{
try
{
try
{
connection.getInputStream().close();//Try to explicitly close the connection
}
catch (Exception e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
connection.disconnect();//Close the connection??
}
catch (Exception e)
{
logger.warning("Failed to disconnect the HTTP connection");
}
}
}
private static int handleResponse(HttpURLConnection connection)
throws IOException, CRPostException
{
String responseMessage = connection.getResponseMessage();//Where it blocks until server returns the response
int statusCode = connection.getResponseCode();
if (statusCode == HttpURLConnection.HTTP_OK)
{
logger.debug("HTTP status code OK");
InputStream in = connection.getInputStream();
try
{
if (in != null)
{
//Read the result, parse it and return it
....
}
}
catch (JAXBException e)
{
}
}// if
//return error state
return STATE_REJECTED;
}//handleResponse()
Server code (Server B):
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
String crXML = null;
MediaType mediaType = null;
Object result;
// Get the media type of the received CR XML
try
{
mediaType = getMediaType(request);
crXML = loadDatatoString(mediaType, request);
result = apply(crXML);
}
catch (Exception e)
{
logger.error("Application of uploaded data has failed");
//Return response that error has occured
....
return;
}
// Finally prepare the OK response
buildStatusResponse(response, result);
// Try to detect that the connection is broken
// and the resonse never got to the client
// and do some housekeeping if so
try
{
response.getOutputStream().flush();
response.flushBuffer();
}
catch (Throwable thr)
{
// Exception is never thrown !!!
// I expect to get an IO exception if the connection has timed out on the client
// but this never happens
thr.printStackTrace();
}
}// doPost(..)
public static void buildStatusResponse(HttpServletResponse responseArg, Object result)
{
responseArg.setHeader("Connection", "close");//Try to set non persistent connection on the response too - no effect
responseArg.setStatus(HttpServletResponse.SC_OK);
// write response object
ByteArrayOutputStream respBinaryOut = null;
try
{
respBinaryOut = new ByteArrayOutputStream();
OutputStreamWriter respWriter = new OutputStreamWriter(respBinaryOut, "UTF-8");
JAXBTools.marshalStatusResponse(result, respWriter);
}
catch (Exception e)
{
logger.error("Failed to write the response object", e);
return;
}
try
{
responseArg.setContentType(ICRConstants.HTTP_CONTENTTYPE_XML_UTF8);
responseArg.getOutputStream().write(respBinaryOut.toByteArray());
}
catch (IOException e)
{
logger.error("Failed to write response object in the HTTP response body!", e);
}
}//buildStatusResponse()
You are running into HTTP connection pooling at the client end. The physical connection isn't really closed, it is returned to a pool for possible later reuse. If it is idle for some timeout it is closed and removed from the pool. So at the moment the server flushBuffer() happened the connection was still alive.
OR
The data being flushed was small enough to fit into the socket send buffer at the sender, so the underlying write returned immediately and successfully, and the disconnect was only discovered later, asynchronously, by TCP.