tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Keep Alive Serverconnection
Date Tue, 19 Nov 2013 19:20:03 GMT
Morten Bo Oelbye wrote:
> I am really schrewed up in this server show.
> I have tryed different suggestion. I do not know how to reuse the 
> response and request connections.
> I end up with the same error.
> java.lang.IllegalStateException: Write attempted after request finished
> Websockets ? How to reuse inputstream and outputstream here?

it sounds like the problem here is due to some lack of understanding of the HTTP protocol,

rather than of understanding of Tomcat and/or HTTP input/output streams.

The HTTP 1.0 protocol is basically built around the following sequence :
- client makes a TCP connection to the server
- server accepts that connection, and waits for more data coming in on it
- client sends a HTTP request on that connection
- server gets the HTTP request
- server processes the HTTP request and builds a response
- server sends the response over the connection
- server closes the connection
- client receives the response and does something with it
- client closes the connection to the server
then, if the client has more requests to send, start back at the beginning.

To the above, the HTTP 2.0 protocol adds one major thing : "keep alive" connections.
What changes is that at the end of the first request, the server and client can decide not

to close the underlying TCP connection, but to keep re-using it :
- client sends a new request on the same connection
- server gets the HTTP request
- server processes the HTTP request and builds a response
- server sends the response over the connection
etc, for a certain number of requests, and/or until a certain time without new requests 
has happened.  Then the server closes the connection.

This "keep alive" thing was added for the purpose of making the dialog between client and

server a bit more efficient, by avoiding having to build a new TCP connection for each new

request, and then throwing it away each time at the end of the request.

But this is all still based on the basic idea of : one request/one response, then again a

request/response, then again...
And each request/response cycle is independent of any other before or after it. Each 
request/response can be handled by a different application on the server (or a different 
instance of the same application).
The point is, from the application point of view, its work is /finished/ when it has sent

the response to the one client request for which it came alive.
And so, for example, the server application cannot send multiple responses over the same 
connection in response to a single client request. And the server application cannot 
decide to send something to the client, without the client having first asked for it by 
sending a new request.

(And that is probably why you are having problems when your application tries to send 
additional data after it has already indicated that the previous response was finished.
It can no longer send data over that same outputstream, because that output stream was 
closed - even if the underlying HTTP connection is "keep alive" and is still open).

Websockets is /another/ protocol, different from HTTP, and designed for allowing just the

things that HTTP does not allow : the client establishes a permanent connection with a 
server application, and from then on they can both exchange "messages" back and forth, 
without any particular order and for as long as they want, over that same connection.

And to make this usable with web servers, there exists a possibility to "upgrade" a HTTP 
connection to a websocket connection :
- the client creates a normal HTTP connection to the server
- the server accepts this HTTP connection
- the client then sends a special HTTP request to the server, asking to "upgrade" this 
HTTP connection to a websocket connection
- the server - if it is "websocket-capable", accepts this request, starts the 
corresponding application, and "gives it" the TCP connection with the client.

 From now on, this application instance and this corresponding connection are dedicated to

this client, for as long as it takes, and they can exchange messages on this connection 
for as long as they want and in whatever order they want (and these messages take a form 
described by the websocket protocol, no longer by the HTTP protocol).

For the application, it does no longer exchange data with the client in the form of HTTP 
requests/responses, it does it in the form of websocket messages (and thus no longer via 
HTTP request/response objects or HTTP input/output streams, but via other kinds of 
websocket-specific calls).

 From the webserver point of view, it is a bit as if the application and the client have 
now "gone to another room" and are having their own private conversation in their own 
websocket language, over their own private connection.

This is also why, on the base of your initial description of "ping-pong" exchanges between

client and server, some people here advised you to use "websockets", because it seemed to

be a better fit than HTTP for what you are trying to do.

But is for you to decide ultimately, and to read on the subject.
For example, start here :
and follow the various links to additional information.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message