[ic] mod_interchange and Apache MaxClients

John1 list_subscriber at yahoo.co.uk
Thu Nov 17 13:22:48 EST 2005

I have a theory that the underlying cause of the problem we are seeing may 
relate (at least some of the time) to timeouts when taking on-line payments 
via the payment modules.

The data is posted to the payment service provider by the post_data 
subroutine in Payment.pm.

The post_data subroutine was updated by Mike Heins in May this year to use 
wget in preference to Net::SSLeay to try to resolve certain issues.  At the 
moment I am using the old Payment.pm which uses Net::SSLeay.

Please have a read of the following posts:



I was then surprised to find a posting from you, Jeff, asking exactly the 
question I have been pondering today:

Anyway, to get back to how this relates to our problem:

What I have noticed in the past is that on days that our on-line payment 
provider has an outage or their service is intermittent, the frequency at 
which Interchange stops responding and needs restarting increases.

We operate a two stage process to taking payment - when a customer places an 
order we send a preauthorisation request to the payment service provider 
(hereafter PSP).  As long as it passes the AVS and CV2 checks the order is 
accepted.  Then, when we come to despatch the goods we take payment through 
an Interchange back office page.  Consequently, on days when our PSP is 
intermittent we also see first hand the effect our customers are seeing.

If we click the "Take payment" button and the PSP server fails to respond to 
the POST request due to a fault at their end our page just hangs.  After 60 
seconds, the browser page goes blank (i.e. white).  Then, after a further 60 
seconds the browser finally times out with the usual "Cannot find server or 
DNS error" page.  Now, the interesting thing is that once this has occured, 
my Interchange session is either very slow at best, or completely hung.  To 
carry on working I must close the browser, clear the cookies and log back on 
again (presumably in order for Interchange to allocate me a new session).

In summary, it seems that Net::SSLeay doesn't close its connection if it 
doesn't get a response.  This is really where my understanding comes to end. 
If Net::SSLeay is still busy "hanging on the line" for a response does this 
mean that any other further attempts to call Net::SSLeay from another 
session will fail?  e.g. another customer trying to place and order?  Or 
should another person's session (and hence interchange process) be entirely 
distinct and unaffected by Net::SSLeay's misbehaviour elsewhere?

Unfortunately my PSP is having an "intermittent service" day today, hence 
the reason for me thinking about whether these problems are connected. 
Anyway, as soon as my PSP is properley back on-line again I will update to 
the new Payment.pm and make the appriopriate "Route" changes to use wget in 
preference to Net::SSLeay to see if this by chance erradicates the IC lockup 

I suggest turning debug on in your interchange.cfg and then uncommenting the 
following debug lines in Payment.pm (assuming you are also using Net:SSLeay 
and not LWP::UserAgent):

::logDebug("placing Net::SSLeay request: host=$server, port=$port, 
::logDebug("values: " . ::uneval($query) );
::logDebug("received Net::SSLeay header: $header_string");

Then, each time the server goes down, review your debug log to see if there 
is an entry for the first 2 debug statement above, but not the 3rd one (i.e. 
the "received Net:SSLeay header").  This would suggest that the server fell 
over waiting for a response to a Net:SSLeay post.  I will let you know if 
this is what I see.

BTW, Jeff, I am interested to know if you ever found out how to set timeouts 
using Net::SSLeay etc.

So, does any one else think there could be a link between Net::SSLeay not 
getting a response and it eventually bringing down the Interchange service? 

Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/

More information about the interchange-users mailing list