Re: Classloader Mysteries

2003-03-29 Thread Theodore Chen
A couple of questions:  How are you deploying the web app?  Is the
daemon thread aware of the Servlet lifecycle?

I have observed that when deploying via the Tomcat manager, there are
cases where the web app is stopped and restarted erroneously. 
Basically, it starts after a deploy, then within a few seconds it stops
and then restarts.  If this is happening and your daemon thread is not
Servlet lifecycle aware and does not stop when the ServletContext is
destroyed, then that daemon is what is pinning your web application and
therefore WebappClassLoader.


On Sat, 2003-03-29 at 00:48, Micael wrote:
 I have created a daemon which I want to startup when Tomcat is started 
 up.  If I configure the daemon to be started with a servlet in web.xml or 
 by using a PlugIn interface and struts-config.xml, I get two daemons 
 running.  How I don't know.  If I don't start the daemon at startup but by 
 tweaking a servlet after startup, where the servlet calls the daemon, then 
 I don't get two daemons.  Does anyone have any idea how this is 
 happening?  I am getting two classloaders of the same type, i.e. same type 
 but different hashcodes.  Anyone know what is going on.  I am running 
 Struts 1.1 and Tomcat 1.1.18.  I have asked this question in a few ways 
 with no responses.  I can find nothing relevant in the archives.  They are 
 both coming from the WebappClassLoader which has as a parent 
 [EMAIL PROTECTED]
 
 Hopefully someone has some assistance, because I am somewhat at a 
 loss.  This must have something to do with the launcher, but I don't know 
 what.  I have tried to get some information for a week out of this 
 list.  Not sure if no one is doing PlugIns, or why there is so little 
 interest in this.
 
 The hashcodes I get for the classloaders are as follows:
 
 
 LOOP: ClassLoader.hashCode(): 728272 Class.hashCode(): 15612583   Check 
 No.: 657) Fri Mar 28 22:47:17 PST 2003 END
 
 
 LOOP: ClassLoader.hashCode(): 20632381 Class.hashCode(): 10973446  Check 
 No.: 659) Fri Mar 28 22:47:19 PST 2003 END
 
 The details on the classloaders are:
 
 LOOP: ClassLoader.toString(): WebappClassLoader
available:
  Extension[org.apache.commons.beanutils, implementationVendor=Apache 
 Software Foundation, implementationVersion=1.4-dev, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
  Extension[org.apache.commons.collections, implementationVendor=Apache 
 Software Foundation, implementationVersion=2.0, specificationVendor=Apache 
 Software Foundation, specificationVersion=1.0]
  Extension[org.apache.commons.dbcp, implementationVendor=Apache 
 Software Foundation, implementationVersion=1.0-dev, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
  Extension[org.apache.commons.digester, implementationVendor=Apache 
 Software Foundation, implementationVersion=1.3-dev, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
  Extension[commons-lang, implementationVendor=Apache Software 
 Foundation, implementationVersion=1.0-dev, specificationVendor=Apache 
 Software Foundation, specificationVersion=1.0]
  Extension[org.apache.commons.logging, implementationVendor=Apache 
 Software Foundation, implementationVersion=1.0.1-dev, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
  Extension[org.apache.commons.pool, implementationVendor=Apache 
 Software Foundation, implementationVersion=1.0, specificationVendor=Apache 
 Software Foundation, specificationVersion=1.0]
  Extension[org.apache.commons.resources, implementationVendor=Apache 
 Software Foundation, implementationVersion=0.1-dev, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
  Extension[org.apache.commons.services, implementationVendor=Apache 
 Software Foundation, implementationVersion=1.0-dev, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
  Extension[Struts Framework, implementationVendor=Apache Software 
 Foundation, implementationVendorId=org.apache, implementationVersion=1.0, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
  Extension[Components Framework, implementationVendor=Apache Software 
 Foundation, implementationVendorId=org.apache, implementationVersion=0.7, 
 specificationVendor=Apache Software Foundation, specificationVersion=1.0]
delegate: false
repositories:
  /WEB-INF/classes/
required:
 -- Parent Classloader:
 StandardClassLoader
available:
delegate: true
repositories:
required:
 -- Parent Classloader:
 StandardClassLoader
available:
  Extension[org.apache.tools.ant, implementationVendor=Apache Software 
 Foundation, implementationVersion=1.5.1, specificationVendor=Apache 
 Software Foundation, specificationVersion=1.5.1]
  Extension[org.apache.commons.collections, implementationVendor=Apache 
 Software Foundation, implementationVersion=1.1-dev, 
 

Memory leak for webapp Manager deploy/undeploy

2003-03-29 Thread Theodore Chen
I believe I'm seeing a memory leak as a result of a Manager
deploy/undeploy.  I have a very simple test case:  a Servlet that has a
static field that refers to an object (Foo) that allocates a large chunk
of memory.  I've instrumented both the Servlet (init(), destroy(), and
finalize()) and Foo (ctor and finalize()).  The Servlet has been
configured to load on startup.

On a deploy, I see:

Foo.ctor (during class initialization of the Servlet)
Servlet.init():

On an undeploy, I see:

Servlet.destroy()
Servlet.finalize()

I never see Foo.finalize().  If I continue to deploy/undeploy
repeatedly, eventually the VM reports an OutOfMemoryError when I try to
deploy.  Running the VM with -verbose:gc and encouraging GC whenever
possible, I see that after each undeploy, memory usage goes up roughly
by what I've allocated in Foo.

Any ideas?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Can't connect to X11 window server using '0:0' as the value ofthe display

2003-03-18 Thread Theodore Chen
Try running the Tomcat VM with the -Djava.awt.headless=true system
property (set it in an environment variable named CATALINA_OPTS).

On Tue, 2003-03-18 at 16:31, Georges Roux wrote:
 Hello everybody,
 
 Hi run Tomcat 4.1.18 Standalone on Linux debian(sid)and use J2sdk1.4.1_01.
 
 I have a servlet which manipulate exif informations in jpg images.
 it works well but when I try to run it on tomcat it fails (error 500)
 
 I have the following error:
 Can't connect to X11 window server using '0:0' as the value of the display
 
 What can I do?
 
 Georges
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Extraneous webapp stop/restart after manager deploy

2003-03-12 Thread Theodore Chen
I'm seeing a potential bug in Tomcat (tested in both 4.1.12
and 4.1.21 Beta) and wanted a sanity check...

Here's the scenario:

I am deploying a simple webapp via the Tomcat 4.1.X manager.
After deploying the webapp once, I update the timestamp on
/WEB-INF/web.xml and redeploy (undeploy followed
by a deploy).  Both by monitoring the default
localhost_log.date.txt log and by using a thread profiling
tool (JProbe threadalyzer), I noticed that there seems to be
a redundant (and erroneous) webapp stop and restart.  I see a stop
and a restart that are caused by the actual deploy and then
within a few seconds, I see a second stop and restart.

In org.apache.catalina.startup.HostConfig, there's a thread
that periodically checks if the deployment descriptor
(/WEB-INF/web.xml) of a webapp has been modified and if it has,
the webapp is stopped and restarted (presumably via a catalina
LifecycleEvent).  If I'm reading the code correctly, there is
a HashMap in HostConfig that contains the last modified times
for the various web.xml files.  It seems that deploying through
the manager webapp does not update this Map (nor is this Map
particularly accessible without some refactoring).

Having a redundant stop and restart may not be bad (though it
would seem to be a bug).  However, I'm trying to track down
a resource leak where I am only able to redeploy 3 or 4 times
before I see an OutOfMemoryError and I am trying to rule out
this stop/restart behavior.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]