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

[miguelele]

If yours is a serious response, it seems that I failed to describe my problem:

The app isnīt just a remote services eater. It does a lot of things: database querying, file processing, data management, sessions, authentication, etc. But there are some points where data MUST come from a remote WSDL service, and these points have become dangerous bottlenecks, because when that remote server goes down o delays its response, ALL THE APPLICATION waits until that process reach timeout or serves the response.

If yours is a funny response, please start your own thread, prefixing it with a "JOKE" keyword, so we can choose to read it when bored.

I have also crossposted this problem in Stack Overflow and SOAP::LITE list, whith any luck.

Any help will be really appreciated:
Miguel

[Anonymous Monk]

But there are some points where data MUST come from a remote WSDL service, and these points have become dangerous bottlenecks, because when that remote server goes down o delays its response, ALL THE APPLICATION waits until that process reach timeout or serves the response.

But you, yourself, said, it tries to contact remote remote SOAP server before every function/runmode -- a self imposed bottleneck.

There is no setting or trick or anything to change inside of SOAP::Lite or Catalyst to fix this problem.

You must fix it in your application.

See Watching long processes through CGI (Aug 02)

Maybe it sounds too simple, but no, I'm not trying to be funny (: its me again Catalyst (app_)server.pl hangs a lot:)

And now for the joke A tiger broke his

<Reveal this spoiler or all in this thread>

 

Think of it a different way, instead of remote soap server, what would you do if it was local database (mysql) server?

Either your app waits and makes your user waits, or it quickly informs the user "here is some cached data" or "sorry, busy now, refresh me in a minute.

I don't have a link handy, but I remember reading an article (about reddit?) where they learned users hate to wait more than they hate old data or an error message, so cache lots of data.

Also worth reading are The Architecture of Open Source Applications (Volume 2): Scalable Web Architecture and Distributed Systems and mod_perl: Building a Large-Scale E-commerce site with Apache and mod_perl

[miguelele]

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

[Anonymous Monk]

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