500 Internal Server Error

[Sigurður Bjarnason <si...@betware.com>]

Hi all
 
I have a website.. witch is in frames, the site is run with Tomcat 4.0.4 and Apache 1.3.
 
The site works fine.. for all parts.. except on frame.. it is a login frame that shows this error.. ( 500 internel Server Error ) although the rest of the site is ok ?!
This .. happens.. once in a while.. not all the time.. ? 
 
Have anyone info on this.. is this frames related.. or something else..
 
regards
Siggi
 

	-----Original Message----- 
	From: Raj Saini [mailto:rajsaini@emerging-trade.com] 
	Sent: þri. 1.10.2002 08:21 
	To: Tomcat Users List 
	Cc: 
	Subject: Re: excessive cpu use with 4.0.4
	
	

	Hi,
	
	I am using the Tomcat 4.0.3 in a very big site. I have few hundereds of
	JSP, around 15 servlets, integrated with JBoss with my own framework
	(which consists around 500 class files. You can think of it a complete
	J2EE implementation of a commercial business application.
	
	Off late, I have been facing the huge memory usage by the tomcat and due
	to this very reason, I need to restart the tomcat every day. I have
	allocated 384 MB of maximum RAM to the tomcat.
	
	Since I did not profile my application, I cant say yet, which one is
	real culprit, tomcat and my application.
	
	I will report back my findings after profiling my application.
	
	Raj Saini
	Seb B wrote:
	> Hi,
	>
	> I'm running a stand-alone Tomcat 4.0.4 (not using jsp, so no need
	> to upgrade to 4.0.5) on Linux RedHat 7.3, with IBM's 1.3.1 jvm.
	> There is very little static content to serve and the server
	> doesn't have to listen on port 80, so I haven't tried learning
	> how to configure it behind Apache.
	>
	> Everything works great in the lab, so I'm now experimenting in
	> our production system (whose servers are running other servlet
	> containers so far), behind a load balancer.
	>
	> On the last run, 4 of the java threads started taking all of the
	> cpu. I stopped sending traffic to tomcat, and those 4 went on
	> taking all the cpu they could (for several days). So it looked
	> like they were stuck in some infinite loop somewhere. Of course,
	> I suspect this would come from our code. I tried enabling all
	> sorts of logging in our code, but couldn't get anything from the
	> process.
	>
	> As a last resort, I sent the process a "SEGV" signal, which leads
	> the jvm to print stack traces. All 4 threads (I knew their PID
	> from ps/top) had the following stack trace:
	>     "HttpProcessor[9090][44]" (TID:0x100502B8,
	> sys_thread_t:0x46DCDD98, state:R, native ID:0x10442) prio=5
	>         at
	> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcesso
	> r.java:1125)
	>         at java.lang.Thread.run(Thread.java:512)
	>          PID: 8013
	> None of the other HttpProcessor threads were on that same line
	> (1125), all those I looked at were (as they should be I guess):
	>     "HttpProcessor[9090][43]" (TID:0x10050300,
	> sys_thread_t:0x46DCD918, state:CW, native ID:0x10041) prio=5
	>         at java.lang.Object.wait(Native Method)
	>         at java.lang.Object.wait(Object.java(Compiled Code))
	>         at
	> org.apache.catalina.connector.http.HttpProcessor.await(HttpProces
	> sor.java(Compiled Code))
	>         at
	> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcesso
	> r.java:1119)
	>         at java.lang.Thread.run(Thread.java:512)
	>          PID: 8012
	> So *if* the stack traces from the jvm are worthwhile, this would
	> point to a tomcat problem.
	>
	> I'm posting to this list and not the developer list, as I'm
	> wondering whether anyone has experienced such a problem before.
	> This has happened in only one of my test runs, I don't know how
	> reproduceable it will be.
	>
	> Also, this has been asked already, but I didn't see many answers:
	> is there any sort of real-world benchmark of what load I can
	> expect in such a set-up ? I understand it depends a lot on what
	> the servlets do, so I'm wondering how big the biggest sites using
	> tomcat are; John Turner mentioned >500k for his, is anyone doing
	> anything bigger ?
	>
	> Thanks a lot,
	>
	> Seb
	>
	>
	>
	> --
	> 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>
	
	


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>