Releasing memory on undeploy

2005-03-18 Thread Simon Kitching
Hi,

I'm one of the committers on commons-logging and am currently looking
into memory-leak issues with j2ee/servlet-engine stuff when undeploying
apps that use commons-logging.

I see the following page in the tomcat FAQ states that classloaders
cannot be garbage-collected in tomcat:
  http://jakarta.apache.org/tomcat/faq/deployment.html

Can someone confirm this is in fact true, and if so explain why?

Thanks,

Simon


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



Re: Windows NT

2005-03-18 Thread Simon Kitching
On Fri, 2005-03-18 at 08:13 -0300, Inove Infoshop Ltda wrote:
 Hi,
 
 Shouldn't TC install under (not manufacturer supported any more) Windows NT 4?
 
 
 I´m  using a product called DeskNow and it uses Tomcat 5.x. Unfortunately (or 
 not), ver 2.6 of the product started using ver 5.x of Tomcat. I use a retired 
 WinNT box as the DeskNow Server, but, when upgrading to version 2.6,
 service registration failed with the following message on Dr. Watson:
 
 Title: desknow.exe
 Exception: access violation (0x0005), Address 0x77f92a66

Well, tomcat itself is a pure-java application. As such, as long as you
have a working java virtual machine you can run tomcat, regardless of
what the operating system is. I'm 99.99% sure that it will still work on
NT as a stand-alone program, so there's always that option as long as
you don't absolutely *have* to run it as a windows service. [1]

But java doesn't support the concept of a windows service natively.
Tomcat does that via the commons-daemon library that provides some
native code to do that on various platforms; see
http://jakarta.apache.org/commons/daemon. I would suggest investigating
what version of commons-daemon your Tomcat instance uses, then have a
look at what platforms that version of commons-daemon supports. If the
latest release has dropped support for NT then you might be able to
install an old release of commons-daemon over what DeskNow bundles. 

There's also the possibility that the crash is not anything to do with
Tomcat, but instead in some custom code provided by DeskNow. You said
that service registration failed but I'm not sure exactly what that
means. Are you sure the crash is occurring within some part of tomcat or
commons-daemon?

[1] Of course if DeskNow is just a java application, then you could also
run it on Linux :-)

Cheers,

Simon



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



Re: deleteOnExit doesn't seem to be working for session temporary files..

2005-03-18 Thread Simon Kitching
On Fri, 2005-03-18 at 10:27 -0800, Joseph Silverman wrote:
 In our setup, we have JSP's that create a temporary file with the 
 deleteOnExit flag set.
 The session timeout (getMaxInactiveInterval) appears to be the 
 default of 1800 seconds (30 minutes).
 
 We are blasting our servlet container (tomcat and jetty) with JSP 
 fetches (that don't handle cookies - http_load if you are curious as to 
 what we are using) and noting that these files stick around till the 
 servlet container itself quits (the java process goes away).  At that 
 point ALL the files are deleted, and it can take HOURS in some cases to 
 do so.
 
 Is this expected behavior?  We think that these files should be deleted 
 when the session expires.  That seems like the right thing to do.

What you are seeing is what I would expect. The javadoc for
File.deleteOnExit very clearly states that the file is deleted *when the
virtual machine terminates*. 

A session is *not* a virtual machine. 

I suggest you use a SessionListener object instead; this should be
invoked when the session expires, and you can delete the files then.

Regards,

Simon


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



Re: Releasing memory on undeploy

2005-03-18 Thread Simon Kitching
On Fri, 2005-03-18 at 18:48 -0800, Chris Hyzer wrote:
  currently looking
  into memory-leak issues with j2ee/servlet-engine
 
 We have about a dozen apps on 2 tomcats that have
 800MB each in linux (5.0.25), and they are not huge
 apps, but after a few manager reloads the tomcat is
 out of memory.  Is this related?  You said undeploy,
 but maybe reloading is also a problem.  Also, if we
 let the server run for a while, we cannot add new apps
 either.  I suspect we need to profile and look for
 memory leaks, but I thought it would mention it.  Chris

It might be the same problem. By undeploy I mean throw away the
classloader associated with the deployed component, which reload will
also do.

The problem is that both commons-logging and commons-beanutils use the
Singleton pattern. And the Singleton pattern is *extremely* hard
(possibly impossible) to implement correctly in a j2ee-style environment
when a class might be loaded via a shared classloader.

Tomcat includes a workaround for commons-logging which appears *to me*
to be a complete fix for commons-logging leaks (though maybe not a very
elegant one): it calls
  org.apache.commons.logging.LogFactory.release(this)
from class WebappClassLoader. However there have been reports of leaks
when using commons-logging despite this; I need to try to set up some
testcases to determine what's going on, but testcases involving
garbage-collection and complex classloading setups will be tricky to
create.

If you do find anything from profiling your app, please post the info to
this group (and/or me).

Note that I'm going to be away for the next three weeks, but will try to
pick this topic up when I return.

Cheers,

Simon


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



Delegate flag for classloading (ATTN: Remy Maucherat)

2005-03-18 Thread Simon Kitching
Hi,

I see here that there is an option for the webapp-specific classloader
to use parent-first classloading instead of the (default) child-first
classloading.

Can someone suggest why this might be useful? Clearly someone thought
so, but I can't see any point in it. It is in catalina since version 1.1
(committer: Remy Maucherat).

See delegate option in this page:
  http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/loader.html

Using this option makes life exceedingly complicated for some libs like
commons-beanutils and commons-logging, so I would like to know under
what conditions someone might enable this feature.

Regards,

Simon


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



Re: [Slightly OT] MVC approach when JSP are not allowed

2005-03-18 Thread Simon Kitching
On Fri, 2005-03-18 at 23:33 -0500, Elihu Smails wrote:
 I am working on a project that uses servlets exclusively.  I would
 like to take advantage of a Model-View-Controller system in order to
 develop my servlets.  For the last servlet project I worked on, I was
 in charge of the back-end data processing and did not have to mess
 with HTML.  This time I do have to roll up my sleeves and play with
 HTML.
 
 So I ask the question.  Since the requirement that I have is to use
 servlets only, can I use something like Struts or Java Server Faces? 
 I am reading some information and it looks like they both rely on JSP
 to ge the job done.

What is the reason for the ban on using JSPs? A JSP page gets converted
into a servlet; in a sense JSP is just a different syntax for writing
servlets in.

If the reason is simply that the architects don't want run-time
compilation of files, or don't want a java compiler available on the
machine then JSPs can simply be precompiled.

Regards,

Simon


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



Re: Logging in Tomcat 5.5

2005-03-17 Thread Simon Kitching
On Fri, 2005-03-18 at 11:25 +0530, Joy Kenneth Harry wrote:
 Hi,
 I have a webapp in tomcat. I am using a separate Log4j.xml for it, in
 its WEB-INF classes folder.
 
 I've also put a Log4j.xml in TOMCAT_HOME/ common/classes and set it to
 false so that I do not get the general Tomcat logs.
 
 But even then my project logs are getting mixed with the TOMCAT logs.
 Is there any way to disable TOMCAT logs.

By project logs do you mean messages deliberately logged by the code
within *your webapp*, or do you mean messages from tomcat itself?

If you are talking about messages logged by code within your webapp, is
it using the log4j API or the commons-logging API?


Regards,

Simon


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



RE: Starting Tomcat results in multiple Java processes

2003-03-11 Thread Simon Kitching
On Wed, 2003-03-12 at 13:43, Chris Dodunski wrote:

 Hi,
 
 Sorry, only just noticed that myself.  Of the two that aren't, I reduced
 minProcessors to 1, and maxProcessors to 2 (server.xml).  But alas, upon
 restarting Tomcat, I still have 26 Java processes running!  Please, what
 must I do to reduce these?

I suggest you chill out, and don't worry about them.

They are *threads* not processes, and a few *hundred* threads really
won't bother any decent operating system. Yes, the ps list looks a bit
messy [that will go away with linux kernel 2.6 :- I presume you are
using Linux] but no harm is being done.

One note: have you got hot deploy enabled? At a guess, there will be a
thread monitoring the .war deploy directory (or one per webapp) which
could be disabled if you can live without hot-deploy. I guess some-one
more familiar with recent tomcat versions than I could confirm/deny
this. However even if it is possible to disable this, you are really
losing functionality for no real gain. 

And setting maxProcessors to 2 means that if *three* people hit a url at
your website concurrently, one will have to wait until one of the
earlier users has finished receiving their page [or pages for http/1.1
persistent connections].

Regards,

Simon



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



Process.waitFor bug which might affect CGIServlet

2003-03-05 Thread Simon Kitching
Hi All,

I have encountered what I believe to be a bug in the Sun JVM (1.4.1 at
least). This causes Process.waitFor() and Process.exitValue() to hang
intermittently. As CGIServlet uses process.exitValue(), I would expect
this bug to also cause this servlet to intermittently hang.

Note that this is NOT due to filling STDOUT/STDERR pipes of the
externally executed application
(http://developer.java.sun.com/developer/bugParade/bugs/4109888.html and
friends).


Firstly, has anyone experienced hangs with CGIServlet?

Secondly, would someone here be willing to help me out by trying the
attached code to verify that the problem can be duplicated? I submitted
a bug to Sun in November 2002, and in Feb 2003 received a cannot
reproduce mail. However I can reproduce it at will. So can at least one
of my clients :-(


I can reliably duplicate the issue on the following systems:

* Mandrake Linux 9.0 on x86:
java version 1.4.1_01
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

* RedHat Linux 7.2 on x86:
java version 1.4.1_01
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

* Mandrake Linux 9.0 with Blackdown linux 1.4.1:
java version 1.4.1
Java(TM) 2 Runtime Environment, Standard Edition (build
Blackdown-1.4.1-01)
Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode)


Exactly the same .class file (compiled with the Sun JDK) works correctly
when run on the following:

* Mandrake Linux 9.0 with IBM JVM 1.4.0:
java version 1.4.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0)
Classic VM (build 1.4.0, J2RE 1.4.0 IBM build cxia32140-20020917a (JIT
enabled: jitc))

* IBM AIX 5 with IBM JVM 1.4.0:
java version 1.4.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0)
Classic VM (build 1.4.0, J2RE 1.4.0 IBM AIX build ca1401-20021126 (JIT
enabled: jitc))

---
How to run the test app:

(a) save runme script, make executable (chmod +x)
(b) compile HangMe.java
(c) java -cp . HangMe runme

The application will print about to waitFor .. waitFor completed about
18 times. Then the text about to waitFor will be displayed and the
application will hang.

Don't forget the runme parameter to tell the app which external
process to invoke - command-line error handling is not implemented :-)

I have a variant of this app which uses a combination of
Process.exitValue(), catch-clause, and sleep() to try to detect external
process termination, but this hangs too, presumably due to the same
underlying issue. This is basically the approach taken by CGIServlet...


Regards,

Simon Kitching
The Electronic Commerce Network Ltd.
#!/bin/sh
#echo runme  runme.out
exit 0
import java.io.File;
import java.io.IOException;

class HangMe
{
  private static void log_debug(String s)
  {
System.out.println(DEBUG: + s);
  } 

  private static void log_debug(String s, Throwable t)
  {
System.out.println(DEBUG: + s + : + t.toString());
t.printStackTrace();
  } 

  private static void log_warn(String s)
  {
System.out.println(WARN: + s);
  } 

  private static void log_warn(String s, Throwable t)
  {
System.out.println(WARN: + s + : + t.toString());
t.printStackTrace();
  } 

  public static void runIt(String appname)
throws Exception
  {
String[] envarray = new String[0];
String[] cmdarray = new String[1];

cmdarray[0] = appname;

File workingDir = new File(.);

Process proc;
try
{
proc = Runtime.getRuntime().exec(cmdarray, envarray, workingDir);
}
catch(SecurityException se)
{
log_warn(Permission refused to run command, se);
throw new Exception(
Permission refused to run command,
se);
}
catch(IOException ioe)
{
log_warn(Unable to run command, ioe);
throw new Exception(
Unable to run command,
ioe);
}

// check process exit status
try
{
log_debug(about to waitFor..);
proc.waitFor();
log_debug(waitFor completed.);
}
catch(InterruptedException e4)
{
throw new Exception(interrupted while waiting for app to end);
}

int exitStatus = proc.exitValue();
if (exitStatus == 0)
{
// success
log_debug(application executed successfully);
}
else
{
log_debug(application failed);
}
  }

  public static void main(String[] args)
throws Exception
  {
String appname=args[0];

for(;;)
{
  runIt(appname);
}
  }
}

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