You confirmed my suspicions. I believe that very few developers employ this, but it seems quite important as requests can get lost relatively often. Anyone think it would be beneficial to have a TimeoutEvent built right in along side ResultEvent and FaultEvent to make it easier?
Baz On Mon, May 3, 2010 at 1:24 PM, jamesfin <james.alan.finni...@gmail.com>wrote: > > > > I agree with Rick. For all net calls, I have a timer going and a simple > queue that is populated when sending each request. When and if they return > sometime later, they are removed from the queue. If requests aren't received > by some set timeout, they are ignored. > > I employ the use of tokens for each request so I know if I should ignore > them or not if they are expired by my timeout. You could also log the > failure to the server or trace if you want to track them. > > james > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, Rick > Genter <rick.gen...@...> wrote: > > > > > On Mon, May 3, 2010 at 1:14 PM, Baz <li...@...> wrote: > > > > > > > > > > > If you send a request to a web service, and for some reason that > request > > > never returns because it got lost on the net, or some other failure. > What > > > strategies do people employ on the flex side to handle that situation? > > > FaultEvent wouldn't fire in this case, because there are no known > faults > > > yet. Perhaps, people employ some timeout functionality on their remote > > > listeners? > > > > > > Cheers, > > > Baz > > > > > > > Do you use a URLRequest/URLLoader to place your request? I think if you > > listen for an IOErrorEvent.IO_ERROR, one gets raised if the request times > > out at the HTTP level. If the request gets to the server but the server > just > > takes too long to respond, then I think you'll have to add some sort of > > timer. > > -- > > Rick Genter > > rick.gen...@... > > > > >
