Just some thoughts based on what Tim has mentioned.
--- Tim Funk <[EMAIL PROTECTED]> wrote:
> I was thinking that too. A big problem with JVM's is
> memory leaks.
I would say a big problem any application is memory
leaks. C and C++ have the same types of issues...just
a little different along with cleaned up pointers
being referenced from other objects no causing access
violations as they are now null(0) or junk.
Profilers can be ran against both types of projects as
long as you can find one for the given platform. Java
is a little easier per the profiler interface.
>The easy
> solution is to restart tomcat. But that causes a
> period of downtime due to
> waiting for a restart.
>
> Why not make mod_ajp "smarter" or create a tomcat
> launcher where some parent
> process (apache, or the launcher) listens for
> requests from the public and
> uses AJP to have tomcat serve the requests. [The
> downside is added latenency]
I like this idea. Something like this:
<Server>
<!--
allowWebApplicationContextVM="false" means
META-INF/Context.xml vm attributes will be ignored or
an error raised
-->
<Host
vm="true"
vmpath="...could allow different JVMs other than
the Tomcat one to be used for a given Host..obviously
the Tomcat version would have to support it...."
allowWebApplicationContextVM="false">
<Context vm="true" vmpath="...could allow
different JVMs other than the Tomcat one to be used
for a given Context"/>
<!-- default to false -->
<Context vm="false"/>
</Host>
</Server>
>
> The parent process can spawn a new tomcat after some
> configurable time and
> kill the old one. By using the cluster code - the
> sessions can be synced
> before the old tomcat goes away.
With the XML scheme above it would watch each JVM
process and restart it after some time.
>
> This mechanism could also be used as a way to
> perform graceful restarts too
> where an web app upgrade is done and reloading
> webapps will cause memory leaks.
Yes each process could then be killed off regardless
of worrying about threads. JVM hooks can be used to
start shutting down the process and the admin can give
the shutdown/restart command of a given context or
host a time limit and if the shutdown fails to take
<=X amount of time then the process will be killed.
The developer will be responsible for only using
daemon threads if they spawn their own threads.....
> [Disclaimer: the above ramblings may not be based in
> reality]
I think it is realistic...obviously it would take some
reworking and a good amount of time....I mean this may
not even be realistic, but it would certainly be more
inline with a good hosting solution and make it more
flexible.
I think using a Tomcat launcher would be best and then
filter AJP through the front process like happens now,
and that process filter to it's sub processes using
AJP because IMO one should be able to only use Tomcat
and not have to use both httpd and Tomcat unless they
just really want to ,and I think localhost TCP/IP
loopback with AJP would be fine as it doesn't have the
same overhead as TCP/IP over a network interface and
will be handled in memory buffers, but being able to
have the Tomcat front end communicate with other
Tomcat front ends over AJP so one could define a host
be ported through this instance to another instance on
another machine would be nice as well so it's all
clustered from the Tomcat configuration and all Tomcat
based....workers could be defined in the server
configuration for a Host or down to the
Context/Application level.
I think it would make sense to have AJP not pool local
loopback connections, and only pool Network interface
connections because they are software based
connections anyways and don't really have anything to
do with an Ethernet (or what ever HW scheme)
connection and a real network connection...they are
much faster....maybe only reuse them if they reach a
certain count as to help avoid running out of TCP/IP
connections on the computer, but reduce that level and
not reuse them unless traffic is very heavy. This way
local loopback AJP can support more connections...and
really how much overhead is avoided by pooling the
local loopback connections (obviously it makes a huge
difference for real connections)?
>
> -Tim
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
