+1  A: 

I don't know about the first problem, but I think your second problem is due to this:

} while (byteIn != -1 && is.ready());

If the sender is not quick enough sending data, the receiver may call is.ready() before the next packet has been sent. This will cause is.ready() to return false which will cause the loop to stop.

The minimal fix is to change that line to:

} while (byteIn != -1);

EDIT

But really, you need to rewrite the method along the lines of @simonlord's answer. It is a really bad idea to read an unbuffered stream one byte at a time. You end up doing a system call for each read call, which is horribly inefficient.

EDIT 2

The reason that removing is.ready() caused delays is because you were not paying proper attention to the HTTP protocol. The problem was the HttpClient code was keeping the request side of the TCP connection open to allow the connection to be reused. The simple (but sub-optimal) solution would have been to configure HttpClient to close the request side of the connection. Your code would have then seen the EOF straight away. What you actually did was another solution.

Frankly you should not even be trying to implement the server-side HTTP protocol unless you are prepared to understand the entire HTTP specification in depth and implement it faithfully. The chances are that an existing implementation will be faster and more reliable than anything that you can knock together. The problem with implementing a subset of the spec is that your server may need to talk to a real browser that uses parts of the spec that you haven't bothered to implement / test.

Stephen C
When I remove the is.ready() the reading time is way too long. It takes about 20 seconds till the response comes back.
polyurethan
+1  A: 

Hi

It might be to do with the second condition in your while loop, the isReady() method might return false when the next read might block - but you don't really care if it blocks or not, so we can simply remove it (you can read more here: http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStreamReader.html#ready%28%29 ). Try changing to this:

byte[] buf = new byte[500];
while((is.read(buf))>-1){
  requestBuffer.append(new String(buf).trim());
  buf = new byte[500];
}

Now you should get the whole request.

simonlord
When I remove the is.ready() the reading time is way too long. It takes about 20 seconds till the response comes back.
polyurethan
When you say the 'response comes back' do you mean it takes 20 seconds to read the request xml into the requestbuffer?
simonlord
The whole request takes ~20 seconds with reading the request xml and sending the response.
polyurethan
Ok i expect that is being caused by another part of your server implementation - try and wrap the main parts (e.g., recieving the request, building the response, sending the response) with some timing code and some print statements. e.g.,long start = System.currentTimeMillis();...receive request...System.out.println("Task blah took: " + (System.currentTimeMillis() - start) + " millis to complete");that should help you norrow down which part of your application is taking the most time.
simonlord
It was my fault. The problem is that the **stream** don't really end. I solved the problem by using the http header parameter 'content-length'. I added the new code snippet to my question. **Edit** And now I'm reading the stream with a buffer...
polyurethan