You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Peter Ertl <er...@moreinput.de> on 2005/10/08 13:07:48 UTC
best strategy for keeping a huge number of web application contexts
Excuse for maybe being a little off-topic...
In my tapestry app users can register for a test version of my
application. whenever this
happens I have to register a new web application context in the web
server
('/user4711' or so).
however the number of registered web contexts can be really(!) high
(+1000
or so).
I am really concerned about memory consumption (and cannot afford a root
server with 10+ gigabytes :-)
java.lang.OutOfMemoryError really sucks as you now...
right now i add a context.xml in tomcat pointing to the similar war file
(app.war). the referenced
libraries from app.war are all located in %TOMCAT_HOME%/share/lib
(commons-logging, tapestry, hivemind, hibernate, etc.).
but still I have the impression that just having the context already
eats
up a few megabytes in tomcat.
does somebody have practical experience on that? is jetty better for
that?
is this setup considered to be robust?
any help greatly appreciated!!!!
Best regards
Peter
RE: best strategy for keeping a huge number of web application contexts
Posted by Patrick Casey <pa...@adelphia.net>.
Peter,
Did you consider just virtualizing within a single context? E.g.
have your login screen ask: Name, Password, Instance? And then have multiple
parallel instances running within the same context? That way you can share
static data, cache, and whatnot between instances and, of course, still be
backed by one and only one physical context.
The only trick is you need to design your app in such a way that
there are clean pinch points to introduce the instance level segmentation. I
force all my DB queries, for example, to go through the same query resolver
so that I can easily append "and instance="foo" to any instance-aware
queries.
I've worked on a *very* large corporate app that used this kind of
segmentation and it worked quite well once we got the kinks out of it. It's
not an easy task to tackle (because it requires touching a lot of parts of
your code), but once you get it solved it opens a whole new world of
application possibilities.
--- Pat
> -----Original Message-----
> From: Peter Ertl [mailto:ertl@moreinput.de]
> Sent: Saturday, October 08, 2005 4:08 AM
> To: tapestry-user@jakarta.apache.org
> Subject: best strategy for keeping a huge number of web application
> contexts
>
> Excuse for maybe being a little off-topic...
>
> In my tapestry app users can register for a test version of my
> application. whenever this
> happens I have to register a new web application context in the web
> server
> ('/user4711' or so).
> however the number of registered web contexts can be really(!) high
> (+1000
> or so).
>
> I am really concerned about memory consumption (and cannot afford a root
> server with 10+ gigabytes :-)
>
> java.lang.OutOfMemoryError really sucks as you now...
>
> right now i add a context.xml in tomcat pointing to the similar war file
> (app.war). the referenced
> libraries from app.war are all located in %TOMCAT_HOME%/share/lib
> (commons-logging, tapestry, hivemind, hibernate, etc.).
> but still I have the impression that just having the context already
> eats
> up a few megabytes in tomcat.
>
> does somebody have practical experience on that? is jetty better for
> that?
> is this setup considered to be robust?
>
> any help greatly appreciated!!!!
>
> Best regards
> Peter
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org