Re^4: SOAP::LITE client timeout makes ALL my Catalyst app to wait

Thank you for keep on trying!

Your help and your links seem to describe the usual world, in which a remote delay makes the user to wait. I can live with it. Mostly because I can't change it by now. If the remote server goes down, its not my problem.

BUT, what wonders me is that all other users must wait too, even if they try pages without SOAP connections

- User "A" requests the page with the remote Web service and waits until timeout because the service is down.

- User "B" (and C, D, E, etc.) can't view any page in the app.

If I run 2 Fcgi processes in nginx, user "B" can navigate without any delay, but if he request the web service during the timeout of "A", all the app gets closed for "D", "E", etc, until timeouts of the previous users.

Isn't it weird????

Miguel

Comment on Re^4: SOAP::LITE client timeout makes ALL my Catalyst app to wait

Replies are listed 'Best First'.
Re^5: SOAP::LITE client timeout makes ALL my Catalyst app to wait by Anonymous Monk on Jun 27, 2012 at 10:50 UTC
BUT, what wonders me is that all other users must wait too, even if they try pages without SOAP connections ... sn't it weird???? No it isn't weird, its simply how it works If client A is timing out, don't let others (like client B) to try to connect, simply assume it will fail also, and report failure (sorry, try again later) This way one of your two app-servers stays alive and clients C D E can get their turn. This is the basic lesson of "Watching long processes through CGI (Aug 02)", much more directly expressed in Highlander: one instance at a time (Oct 00) Its much nicer than users waiting, or getting a gateway timeout from nginx -- gateway timeout means "stupid website is broken" to regular folks	[reply]

Replies are listed 'Best First'.

Re^5: SOAP::LITE client timeout makes ALL my Catalyst app to wait
by Anonymous Monk on Jun 27, 2012 at 10:50 UTC

BUT, what wonders me is that all other users must wait too, even if they try pages without SOAP connections ... sn't it weird????

No it isn't weird, its simply how it works

If client A is timing out, don't let others (like client B) to try to connect, simply assume it will fail also, and report failure (sorry, try again later)

This way one of your two app-servers stays alive and clients C D E can get their turn.

This is the basic lesson of "Watching long processes through CGI (Aug 02)", much more directly expressed in Highlander: one instance at a time (Oct 00)

Its much nicer than users waiting, or getting a gateway timeout from nginx -- gateway timeout means "stupid website is broken" to regular folks

[reply]