austin seipp wrote:
The Ur/Web runtime system represents asynchronous channels for message passing between clients with an ID that is generated by the when a new channel is allocated, and uses this for example when you insert a 'channel' into the database. Would it be possible to move this channel generation into the database itself, perhaps with a sequence or something similar?
Moving name generation into the database is easy, but there is other important state. Fundamentally, we must manage TCP connections by clients, which sounds scary to do with SQL. Each channel has a buffer, and there is locking to manage proper use of the buffers. All this is done now with shared memory on a single host.
I have contemplated supporting application distribution by changing [client] and [channel] representations to store server IDs as well, so that each server can easily manage its own name supply. It would be a run-time error to access a channel associated with a different server. The Ur/Web runtime could be modified to set a cookie that a load balancer or proxy could use to detect requests to the appropriate servers, where the needed channels live. The feasibility of this idea is based on the assumption that it's easy to group mutually communicating clients into cohorts that fit on single servers. (Note that "client" here refers to a single page view, not a single browsing session, making the problem easier.)
HOWEVER... I'm wondering whether it really is important to support application distribution. I can understand having back-up servers that you switch to if the primary server encounters a problem. That model is already supported very well with Ur/Web. You can use hot-swap support in the DBMS, and the only remaining server-side state is the clients and channels, which aren't especially persistent anyway. If all Comet interaction is reset on the occasional server failure, that doesn't seem so awful to me. Again, here we are only talking about failures of a single primary server, so we don't have the usual problem of "rare failure + many servers = frequent failure."
I know it's in vogue today to care about having many servers in production at once, serving the same application. Still, I'm deeply skeptical that this capability matters for more than a handful of web applications that have ever existed. I lean towards using a single very powerful server, with reasonable performance for shared memory across cores.
I'm very interested in arguments to support the claim that it is common for web applications to be deployed best in ways that have multiple servers running application logic simultaneously.
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
