[ic] mod_interchange and Apache MaxClients

Kevin Walsh kevin at cursor.biz
Fri Nov 18 20:08:02 EST 2005


John1 [list_subscriber at yahoo.co.uk] wrote:
> On Friday, November 18, 2005 1:56 PM, kevin at cursor.biz wrote:
> > I just checked the code again, as my earlier followup about
> > resubmissions sounded a little strange.  Mod_interchange will attempt
> > to connect to Interchange a number of times, but will only send the
> > actual request once. 
> > 
> OK, so does this mean that increasing the mod_interchange timeout and
> retries are probably no longer relevant to issues related to PSPs taking
> ages to respond?
>
Yes.  I don't think there's anything that mod_interchange can do to
help with this issue.

> 
> i.e.
> timeout = timeout waiting to get a *connection* to Interchange not waiting
> for a response?
> retries=number of times mod_interchange will attempt to make a
> *connection* 
> to Interchange?
>
Correct.

> 
> So in that case how long will Apache/mod_interchange keep its connection
> open to the Interchange service whilst waiting for a reply from
> Interchange (which in turn, is waiting for the PSP to reply)? 
> Indefinitely? 
>
Mod_interchange will remain connected to Interchange until Interchange
closes the socket at its end.

> 
> So are we any clearer why Net::SSLeay is leading to "terminated output"
> and 500 server errors? 
> 
> Quoting Mike Heins from thread on update to Payment.pm:
> "We are having frequent problems with terminated output with
> Authorizenet and other payment modules using LWP. Symptom is
> a 500 server error from AuthorizeNet, which should be their
> problem, but they claim this is not happening and payment
> is actually being maded despite 500 response from LWP."
> 
> Do we now consider this to be unrelated to the main topic of this thread,
> i.e. the "Interchange stops responding" problem?
>
Unrelated insofar as mod_interchange is involved, I think.

> 
> BTW, normally it is only necessary for me to restart Apache when the
> Interchange website stops responding.  Does this tell us anything about
> whether it is Apache, mod_interchange, or the Interchange service that has
> "locked up"?  Or could it still be the Interchange service thats locked
> up, 
> but this somehow frees itself once Apache is restarted (e.g. perhaps
> allowing the "locked up" Interchange processes to die)?
> 
A socket can be torn down by closing either end.  You'd get the same
effect by restarting Interchange as you get by restarting Apache in
this case.

>
> BTW, *after* restarting Apache I get the following errors in the
> Interchange 
> error.log:
> 
> Died in server spawn: read: closed at .../lib/Vend/Server.pm line 644.
> Died in server spawn: read: closed at .../lib/Vend/Server.pm line 644.
> Died in server spawn: read: closed at .../lib/Vend/Server.pm line 644.
> Died in server spawn: read: closed at .../lib/Vend/Server.pm line 644.
> Died in server spawn: read: closed at .../lib/Vend/Server.pm line 644.
> Died in server spawn: read: closed at .../lib/Vend/Server.pm line 644.
> Server spawn error: Can't use an undefined value as an ARRAY reference at
> .../lib/Vend/Util.pm line 1078.
> Server spawn error: Can't use an undefined value as an ARRAY reference at
> .../lib/Vend/Util.pm line 1078.
> Server spawn error: Can't use an undefined value as an ARRAY reference at
> .../lib/Vend/Util.pm line 1078.
> Server spawn error: Can't use an undefined value as an ARRAY reference at
> .../lib/Vend/Util.pm line 1078.
> Server spawn error: Can't use an undefined value as an ARRAY reference at
> .../lib/Vend/Util.pm line 1078.
> Server spawn error: Can't use an undefined value as an ARRAY reference at
> .../lib/Vend/Util.pm line 1078.
>
That's just Interchange reacting to the unexpected socket closure on
the mod_interchange side.  It's probably safer to restart Interchange
than to restart Apache.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin at cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/



More information about the interchange-users mailing list