Menu
▾
▴
Re: [Soaplite-devel] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX
|
From: Bill H. <bh...@te...> - 2008-01-28 18:11:52
|
This seems to only occur with newly spawned httpd processes - since I am typically killing the most recent child to clean up the issue without restarting apache. I am using prefork - but the perl on AIX I am using was built with threading on - I do not think that should be an issue? I can try the PerlChildInitHandler route - but isn't it the same as doing this in my httpd.conf file: PerlRequire /usr/local/mystuff/conf/startup.pl and in that file I use my module like this: #!/usr/local/perl/bin/perl use ModPerl::Util (); use Apache2::RequestRec (); use Apache2::RequestIO (); use Apache2::RequestUti l (); use Apache2::ServerRec (); use Apache2::ServerUtil (); use Apache2::Connection (); use Apache2::Log (); use Apache2::Const -compile => ':common'; use APR::Const -compile => ':common'; use APR::Table (); use DBI; use MyModule; 1; Thanks for the help! Bill Hess Martin Kutter wrote: > You may safely try the 0.70_x pre-releases - they're basically bug fix > releases. > I have fixed several bugs related to mod_perl in the 0.70 series, but > the only thing related to loading server classes I remember is #30945: > SOAP::Serializer::envelope: Client Denied access to method, but this is > a different issue. > > Can you determine whether "fresh" or "old" child processes fail? > > I don't know how spawning apache child processes works under AIX - you > might try adding a PerlChildInitHandler to pull in the module required > instead of requiring it in the startup.pl, but that's only a guess (see > http://perl.apache.org/docs/2.0/user/handlers/server.html#C_PerlChildInitHandler_ for writing a PerlChildInitHandler). > > Which Apache MPM are you using? prefork or worker? > > Martin > > Am Montag, den 28.01.2008, 12:16 -0500 schrieb Bill Hess: > >> Thanks for the reply - we control both server and client side of >> things in our setup, so I am pretty sure that there is not any older >> version without a search method and I am positive that the module >> exists and httpd.conf is not changing since we control it - and there >> is only one server accepting requests... >> >> The strange thing in our situation is that we have stress tested this >> over and over again and have not missed one request - we were throwing >> 100's of simultaneous requests at it and it did not skip a beat. It >> seems that something else in the OS or another app on the same box >> does something so that when the next httpd child apache starts is >> "lost" - it can find the module - but not the method. If I kill that >> child process, apache will start another one and most times it is OK - >> rarely the new one starts up with "missing" methods, but when it does, >> that is when we see the error. And this only occurs on AIX - we run >> the same modules on Linux, HPUX, even Windows - not a problem... >> >> I was starting to think that the outside influence was the fact that >> we are mounted via NFS and if there is a small blip in the NFS >> connection the method cannot be found, but the module is loaded OK - >> just a theory - but a sys admin here claims that NFS would not have >> those problems - I really do not buy that... >> >> I am going to try the latest development version of SOAP::Lite 0.70_X >> as well - but the issue is hard to reproduce - we basically have to >> wait until it happens. Does anyone think that any fixes put in after >> 0.69 would address this issue? >> >> >> Thanks! >> >> >> Bill Hess >> >> >> >> Robert Landrum wrote: >> >>> Generally, what's happened is the module search path has found a >>> older version of ABC_DB_SOAP where there was no search method. It >>> might also be that ABC_DB_SOAP doesn't exist. This could be due to >>> a change in the remote httpd.conf. The reason it might affect one >>> call and not the next could be because the SOAP server is actually >>> two or more SOAP servers behind a vip or dns rotor. >>> >>> At least that's what happens to me from time to time. >>> >>> Rob >>> >>> Bill Hess wrote: >>> >>>> After my Apache/mod_perl/SOAP::Lite based server is running (on >>>> AIX) for a while and working perfectly, I get the following error >>>> when making a call from a SOAP::Lite client (Linux based): >>>> >>>> Error occurred making remote request call >>>> (Failed to locate method (search) in class (ABC_DB_SOAP) at >>>> /usr/local/perl/ lib/site_perl/5.8.8/SOAP/Lite.pm line 2586.) >>>> >>>> where the method is 'search' and the module name is 'ABC_DB_SOAP' >>>> >>>> If I try to make the same call right away, it may work or I might >>>> get the same error. I assume this is because it tries to use the >>>> same httpd child process. As time goes on and the server is used >>>> more, the frequency of the errors is higher... >>>> >>>> The problem only occurs on AIX (currently using AIX 5.3) and we >>>> are using Apache 2.2.4 and Perl 5.8.8 (built with threading on) >>>> with SOAP::Lite 0.69 from CPAN. Also - the location to all of this >>>> is NFS mounted - I am wondering if it could be a file locking >>>> issue, which I have seen before on AIX. I know this configuration >>>> (NFS mounted) is probably not the best way to run - but in our >>>> environment we have little choice (politics). >>>> >>>> >>>> The entry in my httpd.conf file is: >>>> >>>> <Location /server> >>>> SetHandler perl-script >>>> PerlHandler Apache::SOAP >>>> PerlSetVar options "compress_threshold => 1048576" #30945: >>>> SOAP::Serializer::envelope: Client Denied access to method >>>> PerlSetVar dispatch_to "/usr/local/mystuff/soap, ABC_DB_SOAP" >>>> </Location> >>>> >>>> >>>> Reading the perldoc for SOAP::Lite, it mentions: >>>> >>>> For dynamic deployment you can specify the name either directly >>>> (in >>>> that case it will be "require"d without any restriction) or >>>> indirectly, with a PATH. In that case, the ONLY path that will be >>>> available will be the PATH given to the dispatch_to( ) method). >>>> For >>>> information how to handle this situation see "SECURITY" section.* >>>> * >>>> >>>> I 'use' various Perl modules in ABC_DB_SOAP. pm and also 'use' >>>> them in a mod_perl startup script which is defined in httpd.conf >>>> using PerlRequire - for example: >>>> >>>> >>>> PerlRequire /usr/local/mystuff/conf/startup.pl >>>> >>>> >>>> So I think that this is synonymous to the methods offered in the >>>> SECURITY section of the perldoc. Here is what the startup.pl file >>>> looks like: >>>> >>>> #!/usr/local/ perl/bin/perl >>>> >>>> use ModPerl::Util (); >>>> use Apache2::RequestRec (); >>>> use Apache2::RequestIO (); >>>> use Apache2::RequestUti l (); >>>> use Apache2::ServerRec (); >>>> use Apache2::ServerUtil (); >>>> use Apache2::Connection (); >>>> use Apache2::Log (); >>>> use Apache2::Const -compile => ':common'; >>>> use APR::Const -compile => ':common'; >>>> use APR::Table (); >>>> >>>> use DBI; >>>> use MyModule; >>>> 1; >>>> >>>> >>>> The DBI module is built into my Perl distro, but MyModule resides >>>> under /usr/local/mystuff/ lib. I use PERL5LIB to include this path >>>> to my @INC Could this be an issue? >>>> >>>> I have seen this issue mentioned before by Googling for it, Perl >>>> Monks, etc... - but have not found any definitive solutions. I >>>> have posted this to the soaplite users list without a response. >>>> >>>> Any help would be greatly appreciated - Thanks... >>>> >>>> >>>> Bill Hess >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Soaplite-devel mailing list >>>> Soa...@li... >>>> https://lists.sourceforge.net/lists/listinfo/soaplite-devel >>>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ Soaplite-devel mailing list Soa...@li... https://lists.sourceforge.net/lists/listinfo/soaplite-devel >> > > > |
