[rt-users] Problems with RT4 coexisting with other ModPerl applications

[Ruslan Zakirov]

On Tue, Nov 29, 2011 at 3:32 AM,  <jim.h.berry at 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.