Persistent HTTP Connection

[richip]

Does GWT require a persistent connection between the browser and the
web application server? I notice that in asynchronous service calls,
this is done using a persistent connection. Is this true of all widget
event handlers? Can this be made synchronous and not require a
persistent connection? Is it just one connection per browser?

[Thomas Broyer]

GWT does not require a persistent connection (actually, this can even be an issue with IE). The fact that you see one being used is only driven by your browser and your server somehow "negotiating" what to do (that's just HTTP at work).

I don't understand your last 3 questions.

[Richi Plana]

I just assumed that GWT required a persistent HTTP connection when I read that it handles RPC calls asynchronously. Otherwise how would the server know where to contact the browser at? Am I right in thinking that the asynchronous response to an RPC call is sent back over the same HTTP session and is torn down immediately after?

Another reason I thought that a persistent connection was required was because the browser client seemed to know immediately as soon as the Jetty application server went down, but I guess this is just a special scenario when running the browser client in debug mode (some plugin in IE, I believe).

Please just correct me if I am wrong.
--

Richi

[Thomas Broyer]

On Thursday, January 27, 2011 10:11:52 PM UTC+1, richip wrote:

I just assumed that GWT required a persistent HTTP connection when I read that it handles RPC calls asynchronously. Otherwise how would the server know where to contact the browser at? Am I right in thinking that the asynchronous response to an RPC call is sent back over the same HTTP session and is torn down immediately after?

That's HTTP: a request and a response, within a single TCP connection (and using pipelining and/or keep-alive, you could send multiple requests and receive their responses all in a single TCP connection).

The fact that it's asynchronous from your point of view (the code) is a different thing.

 

Another reason I thought that a persistent connection was required was because the browser client seemed to know immediately as soon as the Jetty application server went down, but I guess this is just a special scenario when running the browser client in debug mode (some plugin in IE, I believe).

The DevMode plugin indeed uses a "persistent TCP connection", but that's a different kind of connection: it talks its own protocol their, not HTTP.

[Richi Plana]

On Thu, Jan 27, 2011 at 2:38 PM, Thomas Broyer <t.br...@gmail.com> wrote:

That's HTTP: a request and a response, within a single TCP connection (and using pipelining and/or keep-alive, you could send multiple requests and receive their responses all in a single TCP connection).

The fact that it's asynchronous from your point of view (the code) is a different thing.

This is what I meant by "keeping the persistent connection open". If multiple requests go on the same TCP connection, how long is it kept alive? How many operations go over it before it is disconnected? My concern is that a GWT application might require a persistent TCP connection with the app server to the point that it hits a system maximum is users leave their application on even though no activity is taking place.

[Alan Chaney]

Try this:
http://download.oracle.com/javase/1.5.0/docs/guide/net/http-keepalive.html

and this:

http://www.io.com/~maus/HttpKeepAlive.html

The salient points are:

0. 'Keep Alive' is really a connection cache.
1. 'Keep Alive' is default on Http 1.1 (and who remembers 1.0?)
2. 'Keep Alive' is basically a way that the server caches the connections for re-use to the client - the operative word is cache. An idle connection will be painlessly recycled for you.
3.There is no specific Keep-Alive timeout - see 2. above.


Typically a given server can support 100+ connections - on Tomcat its a configuration setting - it probably is in all the other app-servers (or at least it should be...) - an 'active' connection is one that actually has data travelling across it, in one direction or another. A modern, high capacity machine can support many more.


HTH

Alan

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.