[ic] mod_interchange and Apache MaxClients
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