You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Shapira, Yoav" <Yo...@mpi.com> on 2003/01/23 15:07:27 UTC
RE: Memory Mgmt Tomcat
Howdy,
The reason no one answered your original question is because it's kind
of ridiculous ;) I don't mean that in an offensive way. I do mean:
- Java has its own garbage collector. Tomcat doesn't need to implement
its own. There is much information on this topic on java.sun.com and
other general java forums.
- Many many many threads have gone on this list regarding garbage
collection and how to tune for it. Search the list archives for more
details.
Yoav Shapira
Millennium ChemInformatics
>-----Original Message-----
>From: Rommel Sharma [mailto:rommshar@cisco.com]
>Sent: Thursday, January 23, 2003 9:11 AM
>To: Tomcat Users List
>Subject: Memory Mgmt Tomcat
>
>Hi!
> I think the answer give to Nate should help, but just in case some
one
>knows how to do performance tuning of Tomcat when heavy objects are
being
>used, for effective 'memory management' then please put some light on
the
>topic.
>Thanks,
>Rommel.
>
>-----Original Message-----
>From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
>Sent: Thursday, January 23, 2003 7:30 PM
>To: Tomcat Users List
>Subject: RE: Resources for a Context
>
>
>Howdy,
>Can you please illustrate a possible use for this feature before you
>start coding it? A use case which can't be addressed by the servlet
>spec, that is. Right now, I doubt such a contribution would be
accepted
>into tomcat's core, so you may not want to waste time writing it at all
>;)
>
>Yoav Shapira
>Millennium ChemInformatics
>
>
>>-----Original Message-----
>>From: David Keyes [mailto:david.keyes@flashline.com]
>>Sent: Wednesday, January 22, 2003 5:10 PM
>>To: Tomcat Users List
>>Subject: RE: Resources for a Context
>>
>>I would be happy to make any modifications that would be required.
>I've
>>spent a bit of time looking around at the source already, but I'm not
>sure
>>what the best approach would be. It would be nice if it could be done
>in a
>>"plugin" kind of way, but after looking around a bit, it seems that
the
>>concept of a single physical directory as a docbase is pretty
ingrained
>>(comments?).
>>
>>So far, I've looked at the following:
>>
>>1. Writing a new catalina Context implementation
>>2. Writing a new jndi DirContext implementation, that would be
>configurable
>>to take multiple directories
>>
>>Of those two, I think #2 makes the most sense, but I have doubts as to
>>whether it would solve the problem. What I'm afraid of is that the
>changes
>>required are peppered throughout the Tomcat codebase. Any pointers
>that
>>you could give me to get me started in the right direction initially
>would
>>be hugely appreciated.
>>
>>The only reason that I'm spending so much energy on this is that for
>very
>>large web applications that are not structured as a webapp, which I
>think
>>is rather common, it would be a HUGE aid in debugging to be able to
>pull
>>something like this off. The code/compile/debug cycle gets a bit
>>cumbersome when one is constantly redeploying large apps. I think for
>>deployment the spec works just fine.
>>
>>Thanks again for your help, and all of your excellent work.
>>
>>Dave Keyes
>>
>>-----Original Message-----
>>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>Sent: Wednesday, January 22, 2003 4:24 PM
>>To: Tomcat Users List
>>Subject: RE: Resources for a Context
>>
>>
>>
>>
>>On Wed, 22 Jan 2003, David Keyes wrote:
>>
>>> Date: Wed, 22 Jan 2003 15:53:22 -0500
>>> From: David Keyes <da...@flashline.com>
>>> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>> To: Tomcat Users List <to...@jakarta.apache.org>
>>> Subject: RE: Resources for a Context
>>>
>>> So what mechanism would you suggest for making MORE than one
>Resources
>>> directory available for a Context?
>>
>>* Modify Tomcat to support multiple resources directories
>> (It's open source :-). Note that you're violating the letter
>> and spirit of the servlet spec's requirements on webapp
>> organization, so it would be problematic accepting such a
>> change back into Tomcat's core.
>>
>>* Use symbolic links (which doesn't help Windows users much).
>>
>>* Build deployment scripts that copy everything you need in the webapp
>> together.
>>
>>Craig
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:tomcat-user-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:tomcat-user-
>>help@jakarta.apache.org>
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:tomcat-user-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:tomcat-user-
>>help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <mailto:tomcat-user-
>unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-user-
>help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Memory Mgmt Tomcat
Posted by Rommel Sharma <ro...@cisco.com>.
Thanks! Thats the lead I was looking for...
-----Original Message-----
From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
Sent: Thursday, January 23, 2003 7:37 PM
To: Tomcat Users List
Subject: RE: Memory Mgmt Tomcat
Howdy,
The reason no one answered your original question is because it's kind
of ridiculous ;) I don't mean that in an offensive way. I do mean:
- Java has its own garbage collector. Tomcat doesn't need to implement
its own. There is much information on this topic on java.sun.com and
other general java forums.
- Many many many threads have gone on this list regarding garbage
collection and how to tune for it. Search the list archives for more
details.
Yoav Shapira
Millennium ChemInformatics
>-----Original Message-----
>From: Rommel Sharma [mailto:rommshar@cisco.com]
>Sent: Thursday, January 23, 2003 9:11 AM
>To: Tomcat Users List
>Subject: Memory Mgmt Tomcat
>
>Hi!
> I think the answer give to Nate should help, but just in case some
one
>knows how to do performance tuning of Tomcat when heavy objects are
being
>used, for effective 'memory management' then please put some light on
the
>topic.
>Thanks,
>Rommel.
>
>-----Original Message-----
>From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
>Sent: Thursday, January 23, 2003 7:30 PM
>To: Tomcat Users List
>Subject: RE: Resources for a Context
>
>
>Howdy,
>Can you please illustrate a possible use for this feature before you
>start coding it? A use case which can't be addressed by the servlet
>spec, that is. Right now, I doubt such a contribution would be
accepted
>into tomcat's core, so you may not want to waste time writing it at all
>;)
>
>Yoav Shapira
>Millennium ChemInformatics
>
>
>>-----Original Message-----
>>From: David Keyes [mailto:david.keyes@flashline.com]
>>Sent: Wednesday, January 22, 2003 5:10 PM
>>To: Tomcat Users List
>>Subject: RE: Resources for a Context
>>
>>I would be happy to make any modifications that would be required.
>I've
>>spent a bit of time looking around at the source already, but I'm not
>sure
>>what the best approach would be. It would be nice if it could be done
>in a
>>"plugin" kind of way, but after looking around a bit, it seems that
the
>>concept of a single physical directory as a docbase is pretty
ingrained
>>(comments?).
>>
>>So far, I've looked at the following:
>>
>>1. Writing a new catalina Context implementation
>>2. Writing a new jndi DirContext implementation, that would be
>configurable
>>to take multiple directories
>>
>>Of those two, I think #2 makes the most sense, but I have doubts as to
>>whether it would solve the problem. What I'm afraid of is that the
>changes
>>required are peppered throughout the Tomcat codebase. Any pointers
>that
>>you could give me to get me started in the right direction initially
>would
>>be hugely appreciated.
>>
>>The only reason that I'm spending so much energy on this is that for
>very
>>large web applications that are not structured as a webapp, which I
>think
>>is rather common, it would be a HUGE aid in debugging to be able to
>pull
>>something like this off. The code/compile/debug cycle gets a bit
>>cumbersome when one is constantly redeploying large apps. I think for
>>deployment the spec works just fine.
>>
>>Thanks again for your help, and all of your excellent work.
>>
>>Dave Keyes
>>
>>-----Original Message-----
>>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>Sent: Wednesday, January 22, 2003 4:24 PM
>>To: Tomcat Users List
>>Subject: RE: Resources for a Context
>>
>>
>>
>>
>>On Wed, 22 Jan 2003, David Keyes wrote:
>>
>>> Date: Wed, 22 Jan 2003 15:53:22 -0500
>>> From: David Keyes <da...@flashline.com>
>>> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>> To: Tomcat Users List <to...@jakarta.apache.org>
>>> Subject: RE: Resources for a Context
>>>
>>> So what mechanism would you suggest for making MORE than one
>Resources
>>> directory available for a Context?
>>
>>* Modify Tomcat to support multiple resources directories
>> (It's open source :-). Note that you're violating the letter
>> and spirit of the servlet spec's requirements on webapp
>> organization, so it would be problematic accepting such a
>> change back into Tomcat's core.
>>
>>* Use symbolic links (which doesn't help Windows users much).
>>
>>* Build deployment scripts that copy everything you need in the webapp
>> together.
>>
>>Craig
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:tomcat-user-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:tomcat-user-
>>help@jakarta.apache.org>
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:tomcat-user-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:tomcat-user-
>>help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <mailto:tomcat-user-
>unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-user-
>help@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>