After a while my Tomcat (5.5) just won't die when I hit the terminate button (including the terminat all button in the debugger).

The CPU runs along at 100% indefinitely.

This happens after working in Tapestry with some rather complicated pages with Tapestry set into "new class every page" mode.

Windows XP Pro
Eclipse 3.1
MyEclipse 4.0.1 (+formal releases up till today 20JAN2006).

I have to go into the Task Manager, find java and kill all the java processes I can find (generally 1).

I also get MyEclipse going into 100% lockout mode when I load a HTML page (again in tapestry).

Is this a know problem?
Is this really a Tomcat issue?
Possible Solutions:
Timeout on waiting for Tomcat to die and then offer a "kill -9 option" for Tomcat.

If I keep killing tomcat regularly then I don't get the problem.. The limit before I get the "can't kill tomcat" is about 20 html pages.

The Eclipse project can be supplied if you want to have a play yourselves.

Thanks.

Tomcat is 5.5.7

java JDK 1.5.0_4

I think I recall people reporting similar behaviour for Tomcat on the Tapestry User list. I don't use Tomcat so I have not paid too close attention. I also recall that the issue was resolved and *was* a Tomcat config issue.

I would suggest you try having a look over there.

Geoff

I believe Geoff is correct, we have never seen this issue before. Please try using Tomcat 5.5.9 and see if the problem is resolved.

will do thanks.

Tapestry in Test/Code/Debug mode creates a LOT of classes (one for each page) and this soon causes heap problems in Tomcat. Actually causing Tomcat to eventually crash the APP with a Heap Problem.

I suppose the problem with it not quitting is related and I will try the newer version.

thnx

Cut from another area......

We used to get the OOME after every dozen or so redeploys in development.
We're using JBoss+Tomcat and it does lose memory after every hot-deploy.

* I looked at the heap with JProfiler. It has a free 10-day-evaluation
version, so if you work quickly it's free. I was happy enough with the
results that I bought a copy. What a concept.

* I found some sloppy references of my own doing. My custom Engine was
hanging onto a reference to the Visits, and the Visit was referring to my
model-layer object graph. Doh. Beware of static non-final instance variables
in the base classes.

* There were two postings on this list on January 31st about OOME.
MindBridge recommended some extra JVM switches which seemed to help avoid
the error after frequent redeploys in development. My complete set of JVM
options is this:

-server -ea -Dorg.apache.tapestry.disable-caching=true
-Xms256m -Xmx256m
-XX:MaxNewSize=256m -XX:MaxPermSize=256m


I haven't seen an OOME in months.

balanceofpower, excellent followup, thank you for taking the time to add it.