soaplite-devel

[Soaplite-devel] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Bill H. <bh...@te...>]

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"
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

Re: [Soaplite-devel] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Robert L. <rla...@ao...>]

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"
> 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

Re: [Soaplite-devel] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Bill H. <bh...@te...>]

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"
>> 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
>
>

Re: [Soaplite-devel] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Martin K. <mar...@fe...>]

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

Re: [Soaplite-devel] Apache 2 - mod_perl - SOAP::Lite 0.69 issue on AIX

[Bill H. <bh...@te...>]

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
>>     
>
>
>