You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2011/06/13 17:55:12 UTC
DO NOT REPLY [Bug 51366] New: One process per webapp
https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
Bug #: 51366
Summary: One process per webapp
Product: Tomcat 7
Version: unspecified
Platform: PC
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: cowwoc@bbs.darktech.org
Classification: Unclassified
I don't know whether this proposal has been made before so I apologize in
advance if I'm rehashing an old idea. I'd like to propose a simple but powerful
architectural change: each webapp should run in its own JVM.
Benefits:
* Ability to manage resources (memory, cpu, etc) on a per-webapp level
* Improved fault-tolerance (a failing webapp won't take others down with it)
* Ability to load JNI libraries from webapps without having to jump through any
hoops or running into "java.lang.UnsatisfiedLinkError: Native Library x already
loaded in another classloader."
Please let me know what you think.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51366] One process per webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
--- Comment #4 from Pid <bu...@pidster.com> 2011-06-13 16:54:14 UTC ---
(In reply to comment #3)
> If you don't accept the premise of a full-blown architectural change, is it
> possible to convert this RFE into a mechanism for reloading the webapps in the
> manner specified above? It would fix the UnsatisfiedLinkError I mentioned
> above, memory leak problems that have been plaguing us for years, while
> maintaining quick reloads.
Have a read of:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment
If you want to discuss this, the Users List is the place to do it.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51366] One process per webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
OS/Version| |All
--- Comment #1 from Mark Thomas <ma...@apache.org> 2011-06-13 16:03:37 UTC ---
Just run multiple Tomcat instances. The overhead is minimal.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51366] One process per webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
--- Comment #2 from Gili <co...@bbs.darktech.org> 2011-06-13 16:18:29 UTC ---
Mark,
This isn't a matter of overhead. It's a matter of convenience. By providing a
single management interface for multiple webapps you could enhance productivity
that is not possible by using separate Tomcat instances today.
For example: when a user asks to reload a webapp, you could preload
Tomcat-minus-webapp sitting idle in the background. When the reload requests
come in you simply shut down the old JVM and load the new webapp into the
waiting JVM. If I were to implement this today the act of shutting down an
instance and relaunching it serially would take a lot longer (and thereby
reduce development productivity).
What do you think?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51366] One process per webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
--- Comment #3 from Gili <co...@bbs.darktech.org> 2011-06-13 16:26:20 UTC ---
If you don't accept the premise of a full-blown architectural change, is it
possible to convert this RFE into a mechanism for reloading the webapps in the
manner specified above? It would fix the UnsatisfiedLinkError I mentioned
above, memory leak problems that have been plaguing us for years, while
maintaining quick reloads.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51366] One process per webapp
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51366
--- Comment #5 from Gili <co...@bbs.darktech.org> 2011-06-13 17:29:37 UTC ---
Done: http://old.nabble.com/One-process-per-webapp-to31836121.html
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org