Re:constantly open connections in TC

[Ken Bowen <kb...@als.com>]

I haven't stepped up to attempting Comet/NIO yet, but I have had
some small-scale success with a custom pseudo-push implementation
using the RPC in GWT (Google Web Toolkit); obviously we're using GWT  
for the pages.
When the browser starts, it uses rpc to ask for any available data:
    If data is ready, the server responds immediately, and then the  
browser asks again.
    If no data is available, the server implementation of the rpc  
executes wait() until
        the main server control executes notifyAll(), and the (newly  
available) data is returned
        to the browser,  which then asks again, etc.
Very conservative polling because of the wait/interrupt, but it ties  
up threads:  hence the "small scale".
This is ok for an application where the number of logged-in users is  
strictly controlled.
Since we will eventually scale up, I'll be trying out Comet sooner or  
later.

--Ken

On Aug 8, 2008, at 11:19 AM, Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Albretch,
>
> Albretch Mueller wrote:
> | 1) Can you achieve such a thing as a registered, dedicated, always
> | open connection to each client in a network from login to logout  
> using
> | tomcat?
>
> Not really. HTTP is designed as a connectionless protocol. You might  
> be
> able to do this using the Comet Connector (about which I am completely
> ignorant).
>
> These days, everyone uses AJAX to make web applications appear to have
> constantly-updating screens and things like that.
>
> |  1.1)  How can browsers be configured to take advantage of them?
>
> Server-push is an option, but is sucks. AJAX is your best bet IMO. Or,
> use an entirely different protocol instead of HTTP (you could do this
> using a Flash-based app or a Java applet).
>
> |  1.2)  What would you suggest if I would like this configuration  
> to be
> | available to different browsers, the user may have?
>
> Flash is much more available than Java for web browsers.
>
> |  This would be beneficial if you want to use an internal, local
> | network cache for a number of users you know in a network you own
> | ~
> |  Which each user's login a connection is open transparently to that
> | user in a tomcat server that just works as a cache. Different users
> | are not supposed to trample on each others' connections
>
> What's wrong with a standard HTTP-based web application with requests
> and responses?
>
> |  2) In the (2004) article "Concerning Etags and Datestamps"
> |
> | [snip]
> |
> | The part I wouldn't totally agree with or that is not clear to me is
> | "The first method involves an extra connection for each download,
> | which takes time and server resources."
> |
> | I think when you hit a server with a "HEAD" request, the server just
> | returns the meta-data without trying to setup sessions
>
> Not necessarily. The server can do anything it wants to do. A HEAD
> request is handled separately from the (possible) following GET  
> request,
> so if there are headers to be parsed and resources to check (such as  
> the
> size of a file, etc.), all that work will have to be done for the HEAD
> request before anything can be sent back. That same work is likely  
> to be
> repeated when the GET request comes a moment later.
>
> | or "keep-alive"
> | connections from that client in an unencumbered way, but if you  
> "GET"
> | connections to server resources, servers will do the setup to  
> estabish
> | ongoing connections to that client, so then when you drop the
> | connection after reading the headers, servers do keep the connection
> | open wondering that went of with the client . . .
>
> No, the server should see a dropped connection and just close and
> cleanup the connection on the server side. It's true that a lot of  
> work
> might be needlessly done on the server side if the client just plans  
> to
> hand up the connection.
>
> |  So, I think it you know that the server most likely didn't change
> | some data and that the particular server reliably reports HTTP
> | headers, then it is better to conditionally go with "HEAD" first
> |
> |  Is it true? Am I missing something?
>
> I agree with the author that using If-Modified-Since and similar
> strategies are the best bet because you are basically doing a HEAD +  
> GET
> with a single request. There are special response codes for the server
> to use when the response should be "content has not been modified"
> versus "content has been modified, and here it is".
>
> Feel free to use HEAD followed by GET, but GET with predicates is
> certainly going to be faster if the server correctly supports the
> predicates themselves.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkicZA0ACgkQ9CaO5/Lv0PBfvQCgh7CIJNXXy8echulIxOXqbsSL
> i40AoJ7UxsEslVo+lFoBERtyVA8UcO3U
> =IW8M
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org