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?


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.


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/ 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"
PerlSetVar dispatch_to "/usr/local/mystuff/soap, ABC_DB_SOAP"

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/

So I think that this is synonymous to the methods offered in the SECURITY section of the perldoc. Here is what the 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;

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 email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.


Soaplite-devel mailing list