On Tue, Nov 29, 2011 at 3:32 AM, <jim.h.be...@frb.gov> wrote: > Hi List, > > This is no longer a problem for us, because we will be running RT on its > own separate server. But in case anyone is interested...
I believe the following option may help: http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ > > When we installed RT v4.0.4 on our production linux Apache2/ModPerl server, > we discovered a conflict with other Mason/ModPerl applications. When we > disable the other ModPerl apps, RT4 is fine. We did not have this problem > with RT v3.8.x. It is quite possible that something is not quite right > with the other applications, but they have been running smoothly for years. > They are using Mason, but not PSGI. They each have their own Mason cache > area. > > The symptom is an occasional 500 error from any RT web page, with lines like > this in the log: > > Undefined subroutine CGI::PSGI::SUPER::read_multipart\n at > /opt/perl-512/lib/site_perl/5.12.3/HTML/Mason/PSGIHandler/Streamy.pm line > 15\n, referer: https://www-test/rt4/Ticket/Create.html?Queue=26 > > (other CGI::PSGI subroutines too). Hitting reload or shift-reload will > initially bring up the correct page, but after a while all of the child > processes will seem to be polluted and RT becomes unusable. The other > ModPerl application web pages are fine. > > We are running: > Linux RHEL 5 (but install our own perl and apache) > Apache 2.2.21 - prefork > ModPerl 2.0.5 > HTML::Mason 1.45 > Plack: 0.9982 > PSGI: 1.03 > > Let me know if interested in more details. > > -- > Jim Berry > -------- > RT Training Sessions (http://bestpractical.com/services/training.html) > * Boston — TBA > -- Best regards, Ruslan. -------- RT Training Sessions (http://bestpractical.com/services/training.html) * Boston TBA