[rt-users] Hanging Login Page (ModPerl2, HTTPD, Oracle, RHEL5)

Charles Kugelman Charles.Kugelman at kaplan.com
Tue Apr 7 15:23:15 EDT 2009


Ken,

 

Thanks for the response. The problem in fact presents itself even before
we get to that point (the home page). Essentially, it's the login page
where we see the problem. We come in (in the morning, after RT has been
sitting all night with no activity) and open our browsers and we're not
presented with the login page, but instead just a white page which
proceeds to "load" for 20 minutes before we're finally prompted for
login. As noted, jamming the F5 button several times will "nudge" the
login page to appear instantly. CPU util is nearly nothing all the time
on this VM, as well.

 

Our Oracle DBA has enabled debugging on that database, so maybe we'll
know something more tomorrow.

 

On a side note, we noticed that KeepAlive was set to "Off" by in the
httpd.conf. Apache's website says the default is "On." Sort of odd on
that, but I changed it to "On." Not sure why this would cause this sort
of problem, but I'm grasping.

 

Thanks!

 

-CK

 

________________________________

From: Ken Crocker [mailto:kfcrocker at lbl.gov] 
Sent: Tuesday, April 07, 2009 3:05 PM
To: Curtis Bruneau
Cc: Charles Kugelman; rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Hanging Login Page (ModPerl2, HTTPD, Oracle,
RHEL5)

 

Charles,


    WE also have Oracle, but we are on 3.6.4. I have noticed that when I
first bring up RT, it takes a little while, ESPECIALLY if I have some
queries I selected for my home page. I'm not a DBA, nor a UNIX
specialist, but as I watch my computer take a long time with the initial
loading, I wonder if there are some sort of size parametrs that can be
set that allow for larger batches of cache data, buffered data or
whatever to be loaded faster. I/O always takes way more time to process
than internal commands, so I just figured that the excess time was due
to the fact I may be loading a search/result that goes to a table with a
poor index or key. Or perhaps I have too many user with wide-open
permissions and all that I/O to check the different DB Tables for
permissions, etc was taking all the time.
    I'd try changing your home page to NOT pull ANY searchs and see how
that affects the loading time. If it is still incredibly slow, then
there must be some setting that affects data transfer size that might
help.
    Just a couple dumb thoughts.


Kenn
LBNL

On 4/7/2009 10:49 AM, Curtis Bruneau wrote: 

Just realised you are using Oracle, but the bug seems almost identical.
 
Curtis Bruneau wrote:
  

	Seems a lot like the DBD::MySQL bug that many people have had
with 
	older versions, basically the children are segfaulting on some
timeout 
	bug. During a refresh the parent process is reaping the child
and 
	restarting it with a functional process, which is why it appears
to 
	take several refreshes to get a page view. I think the last
several 
	versions have fixed this.
	 
	Charles Kugelman wrote:
	    

		Update on this:
		 
		I've noticed that while this is happening, I can hit F5
(refresh) a 
		few times and the page will then successfully load.
		 
		Any ideas?
		 
		** **
		 
		**-CK*** *
		 
	
------------------------------------------------------------------------
		 
		*From:* rt-users-bounces at lists.bestpractical.com 
		[mailto:rt-users-bounces at lists.bestpractical.com] *On
Behalf Of 
		*Charles Kugelman
		*Sent:* Monday, April 06, 2009 8:33 AM
		*To:* rt-users at lists.bestpractical.com
		*Subject:* Re: [rt-users] Hanging Login Page (ModPerl2,
HTTPD, 
		Oracle, RHEL5)
		 
		Update on this:
		 
		I've updated httpd, httpd-devel, mod_perl, mod_ssl to
the latest 
		version. Problem still exists.
		 
		One additional thing to note is that this is running as
a virtual 
		machine (on ESX) with 1GB of memory allocated.
		 
		**-CK****
		 
	
------------------------------------------------------------------------
		 
		*From:* rt-users-bounces at lists.bestpractical.com 
		[mailto:rt-users-bounces at lists.bestpractical.com] *On
Behalf Of 
		*Charles Kugelman
		*Sent:* Friday, April 03, 2009 11:36 AM
		*To:* rt-users at lists.bestpractical.com
		*Subject:* [rt-users] Hanging Login Page (ModPerl2,
HTTPD, Oracle, 
		RHEL5)
		 
		Greetings RT Gurus!
		 
		--Problem--
		 
		Every morning when I sit down at my desk and point my
browser to RT, 
		it hangs when the login page should be displayed.
Usually I've just 
		performed a "service httpd restart" to resolve the
problem. This 
		morning, I just let it sit and load for in excess of 20
minutes, and 
		the page finally appeared, after which RT seemed to be
performing 
		fine - even if I restart my browser and head back to the
logon page. 
		This did happen in the middle of the day yesterday as
well, to which 
		I restarted httpd, as normal. This, obviously, won't
work for 
		production (which we plan on this system being shortly).
I'm sending 
		this message in the hope that someone can assist me with
this problem.
		 
		--Relevant Info--
		 
		- RT Version: 3.8.2
		 
		- HTTPD Package (RPM): httpd-2.2.3-6.el5
		 
		- Mod_Perl Package (RPM): mod_perl-2.0.2-6.1
		 
		- Perl Package (RPM): perl-5.8.8-18.el5
		 
		- OS: RedHat Enterprise Linux 5
		 
		- Oracle Client: 10.2, Instant Client
		 
		- Oracle Server (remote server): 11g
		 
		- Mail Package (RPM): postfix-2.3.3-2
		 
		- I've done some digging in the archives and found the
post by Dirk 
		Pape (subject: Performance-Bug in SelfService when
updated from 3.6.1 
		to 3.6.3, date: Jan 22, 2007, 11:39 PM) and the issue
seems to be 
		very close to what I'm seeing. But the resolution that
Dirk used 
		doesn't seem to apply to the current version of RT, as
"@roles => 
		('Watcher')" is already set in the 
		html/SelfService/Elements/MyRequests file by default.
And my seems to 
		be with the logon page.
		 
		- I have added the following lines to httpd.conf in
order to force 
		http:// requests to use https:// (don't know if this may
have some 
		sort of impact).
		 
		RewriteEngine On
		 
		RewriteCond %{HTTPS} off
		 
		RewriteRule (.*) https://% <https://%25>
{HTTP_HOST}%{REQUEST_URI}
		 
		- Could the way Postfix is configured be causing this
problem? The 
		problem seemed to come into play when I started working
on the mail 
		components.
		 
		--Non-Standard Features Being Used--
		 
		- SSL (on the front end)
		 
		- RT External Auth Plugin (authenticating successfully
against AD)
		 
		--What Seem to be Relevant Error Log Outputs--
		 
		- /var/log/httpd/access_log: The error below seems to be
appearing 
		quite frequenetly. I'm not sure if it's related or not,
but doesn't 
		look good.
		 
		(RTHOST) - - [03/Apr/2009:09:51:57 -0400] "POST 
		/REST/1.0/NoAuth/mail-gateway HTTP/1.1" 302 333 "-"
"libwww-perl/5.805"
		 
		- None of the other logs that I've checked (httpd
error_log, rt log) 
		appear to have anything of relevance to this problem.
		 
		Thanks in advance for any assistance you may be able to
offer.
		 
		-CK
		 
		No virus found in this incoming message.
		Checked by AVG - www.avg.com
		Version: 8.5.283 / Virus Database: 270.11.38/2037 -
Release Date: 
		04/03/09 06:19:00
		 
		No virus found in this incoming message.
		Checked by AVG - www.avg.com
		Version: 8.5.285 / Virus Database: 270.11.42/2042 -
Release Date: 
		04/06/09 06:22:00
		 
	
------------------------------------------------------------------------
		 
		_______________________________________________
	
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
		 
		Community help: http://wiki.bestpractical.com
		Commercial support: sales at bestpractical.com
		 
		 
		Discover RT's hidden secrets with RT Essentials from
O'Reilly Media. 
		Buy a copy at http://rtbook.bestpractical.com
		      

	 
	    

 
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
 
Community help: http://wiki.bestpractical.com
Commercial support: sales at bestpractical.com
 
 
Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com
 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20090407/d752afcf/attachment.htm>


More information about the rt-users mailing list