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 
Soaplite-devel@lists.sourceforge.net 
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 Soaplite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soaplite-devel