On Saturday, November 19, 2005 6:36 PM, suppressed wrote:
I mentioned a scenario earlier in this thread that *always* causes my Interchange session to hang: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.
############ 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
_______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.