Have you tried running in debug and inspecting the FaultEvent manually? Since it's a HTTPService call it might return a FaultEvent with a HTTPResponse code (instead of a 200 maybe something more meaningful) or some such that's populated differently than the AMF call.
Looking at the FaultEvent API you might look at the statusCode field or the content Object in the FaultEvent's Fault object to see if it has the HTTPResponse data you need to see that it was a session timeout (or if it was an exception the 500 or whatever server error response is coming back down the pipe). There's also the headers Object on the FaultEvent and the ErrorMessage which might contain the data you need. If you're feeling really fancy you can use WebScarab or some such to intercept the HTTPService response and inspect the HTTP headers manually to see if those give you any more insight. Anyway, good luck with that. -Marty On Fri, Aug 21, 2009 at 12:53 PM, Dale Bronk <[email protected]> wrote: > Right, I'm not trying to catch it on the client. The server is catching it > and throwing an exception as per our design. That causes a FaultEvent, not > a ResultEvent. When we make AMF calls this is handled perfectly. Server > side throws an exception. Our AMF fault handler interrogates the > FaultEvent > and sees that it is a session time out and handles it. But, when we make > the HTTPService call the server still does what it is suppose to and throws > an exception and that still causes a FaultEvent, but in our fault handler > for the HTTPService call I do not see anywhere in the FaultEvent anything > that tells me what the issue was. > > Our code for handling the AMF faults is: > > // Some non important to this issue code > > var errorMessage : ErrorMessage = ErrorMessage(faultEvent.message); > var rootCause : Object = errorMessage.rootCause; > if ( rootCause != null ) > { > // We have our own well known exception with properties that > tell us what went wrong. > var errorType : String = ( rootCause.hasOwnProperty("type") > ? String(rootCause.type) : null ); > if ( errorType == "INVALID_OR_EXPIRED_CREDENTIALS" ) > { > // Code to publish a session time out to the > application > } > > // Other non important to this issue code > } > > The problem is that even though we throw the same exception, when it is a > HTTPService call this information is not in the FaultEvent. I see no > information from our backend processing at all anywhere in the FaultEvent. > > Thanks, > Dale > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Cameron > Childress > Sent: Friday, August 21, 2009 12:11 PM > To: [email protected] > Subject: Re: [AFFUG Discuss] Session timeout > > The session timeout occurs because the client hasn't connected in a > long time. This occurs on the server, while not connected to the > client. So.... I may be wrong but I don't think you are ever going > to get a client side Flex Event since this all occurs because the > client hasn't been around in awhile. > > You can always catch it on the server and then have the Client check > for a flag when it reconnects to see when the server session timed > out. > > Someone please correct me if I am wrong. > > -Cameron > > On Fri, Aug 21, 2009 at 10:40 AM, Dale Bronk<[email protected]> wrote: > > Anyone have a good pattern for detecting a session timeout for an > > HTTPService call? We use Java on the backend and while we through a good > > exception on the backend, it doesn’t seem to make in the FaultEvent. > I’ve > > looked everywhere in the FaultEvent and just can’t find any mention of > the > > true exception that was thrown. We have one small portion of the app > that > > is HTTPService calls and the rest is AMF using GraniteDS. We can handle > the > > AMF calls no problem as we can access the Java Exception that was thrown > but > > I’m stumped for the HTTPService calls. > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the > subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > >
