Re:[jetty-discuss] How many simple webbaps can jetty support

[James R. <jlr...@so...>]

I used to run a single Jetty installation w/many contexts / webapp 
contexts as a central
servlet server container for students to bang on in a university 
setting. With a reasonable
amount of extension code + servlet hooks to said code, students could 
deploy their own
webapps using HTTP gestures to the privileged servlets. Lessons learned 
in this
endeavor were:

	1) Jetty resources per webapp were light. Student code resources were 
not
necessarily light. "My first database webapp" attempts can be downright 
evil on
a shared box.

	2) Java security managers can control access to some things, but not 
nearly
everything that could amount to a denial of service, such as:
		Memory usage
		CPU usage
		I/O descriptor usage per allowed descriptors (easy to say
			"only allow file creation in /tmp", impossible to say
			"allow at most 5 filehandles to /tmp for this webapp".

	Since you'd be running your own 'trusted' code, many such issues
would be avoided, but your own mistakes / leaks could still bring the 
big
house down.

	3) Extending Jetty to support admin actions along the lines of
'deploy new store named X', involving the following, should be
straightforward:
		A) instantiate new webapp context from template.
		B) enable new virtual host to the HTTP listener. Probably would want
to do some plumbing glue to bind said virtual host to their 'personal' 
webapp -- so
that http://www.storeX.com/index.html gets rewritten ala mod_rewrite to 
that per-store
webapp context mounted at URI /storeX/index.html -- not sure how this 
would be
done offhand). As pointed out elsewhere, HTTPS personal branding would 
be
much more difficult, due to SSL cert name requirements. Best bang / 
buck for the
'checkout' phase to use the one true generic non-branded name.

	Separate database instances / each store data cleanly isolated from 
each
other through separate databases or schemas would be the way to go, 
since little
data would be expected to be shared between individual stores (as 
pointed out
elsewhere).

	The separate webapp solution would also allow you to relatively easily 
split
webapp load across multiple webservers when the time came -- bring up 
new box,
then migrate half of your client webapps from overworked box to new 
box. Likewise
if database is getting overworked -- pop in a new database box, migrate 
N stores
database data (cleanly separated in separate table namespaces) to new 
database
server, and rock and roll. Beats having to extract out random rows of 
the big tables.

	The Jetty extension code would be the fun part, allowing you to 
turnkey the
creation of a new store pretty easily. That then leaves you the 
drudgery of the
app-level webspace code :-(

----
James Robinson
Socialserve.com