How to trap SOAP client timeout

cormanaz has asked for the wisdom of the Perl Monks concerning the following question:

I have a SOAP client that periodically updates a remote server. I call it like so

my $server = SOAP::Lite                                             
  -> uri('http://www.soaplite.com/duplsvr')                           
+                  
  -> proxy('http://my.ip.com/cgi-bin/server.cgi', timeout => 60);
$result = $server->process($data);
[download]

Occasionally, the client can't reach the server and it times out. When this happens it throws an error that crashes the client.

What I want to do is is put $data on a stack for a later try. But in the case of the timeout I don't even get a chance to check for $result->fault before the client crashes. Is there some way to trap the timeout so the client doesn't crash?

TIA......Steve

Comment on How to trap SOAP client timeout Download Code

Replies are listed 'Best First'.
Re: How to trap SOAP client timeout by jhourcle (Prior) on Dec 06, 2005 at 19:40 UTC
From the SOAP::Lite docs: on_fault() This lets you specify a handler for on_fault event. The default behavior is to die on an transport error and to do nothing on other error conditions. You may change this behavior globally (see "DEFAULT SETTINGS") or locally, for a particular object. So, you would use: `my $server = SOAP::Lite -> uri('http://www.soaplite.com/duplsvr') + -> proxy('http://my.ip.com/cgi-bin/server.cgi', timeout => 60) -> on_fault( sub { } ); # ie, do absolutely nothing` [download]	[reply] [d/l]
Re^2: How to trap SOAP client timeout by cormanaz (Deacon) on Dec 09, 2005 at 13:58 UTC
Doh! Thanks for the pointer. Should have checked the docs more carefully. I actually tried the eval solution suggested by gu and it has been working, but this seems like a more proper way to do it.	[reply]
Re: How to trap SOAP client timeout by gu (Beadle) on Dec 06, 2005 at 18:56 UTC
I don't know if I understood the problem very well... but "some way to trap the timeout so the client doesn't crash" makes me think about using eval to catch run-time errors. Gu	[reply]