[ic] mod_interchange and Apache MaxClients

[John1]

On Saturday, November 19, 2005 6:36 PM, jeff at hisgirlfridays.com wrote:

> On Sat, Nov 19, 2005 at 01:08:02AM -0000, Kevin Walsh wrote:
>
>> Mod_interchange will remain connected to Interchange until
>> Interchange closes the socket at its end.
>
> Or until the apache hard timeout is reached, IIRC.  Although mod_ic
> might not be the culprit on this issue, it could mitigate the issue.
> It's clearly "stuck" somewhere waiting for something to happen.  Maybe
> at connect?  Would it make sense to set up a hard timeout at the
> beginning of mod_ic's code path and kill it at the end?  The current
> code only sets timeouts during RX, TX, and select but not during
> connect.  In the end, it seems like mod_ic's entire exchange with IC
> should not exceed apache's hard timeout value and I don't believe that
> the current code ensures this.
>
I mentioned a scenario earlier in this thread that *always* causes my 
Interchange session to hang:


############
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).
#############

This particular scenario may or may not be related to the main problem we 
have been discussing in this thread.  However, it must be related to 
timeouts et al, and it occurs to me that one good way to test the effect of 
a payment gateway's failure to return a response to a POST request would be 
to write a dummy payment gateway.

The code would need to listen out for a POST request on a particular port, 
wait for a given length of time, and then respond with a simple status 
result.  The length of time that the code should wait between accepting the 
POST request and responding should be made configurable.  Indeed, the 
timeout value could be passed from the client in the POST request.

This would allow the scenario I describe above with payment gateway timeouts 
to be reproduced and would hopefully be a useful tool in investigating 
whether timeouts are being handled properley.

I am afraid that writing this code is beyond my ability, but I thought I 
would mention the idea in case anyone wished to take on the challenge.  I 
would be happy to take part in any timeout tests using the dummy payment 
gateway. 


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com