I had thought about it, but I really don't like the idea of managing session timeout on the client and the server. That is a server job and no matter how careful you are, it is bound to get out of sync. Also, our app will change the session timeout depending on the time of day and that would mean then having to manage that on the client as well. I'm really very shocked that my exception is getting eaten somewhere and not being brought back to me. This tells me that if you do HTTPService then fault handling is useless as you will never know what happened. Right now I'm going down the path of creating a servlet filter that will hopefully be able to change the http status code and use that. I'll let you know if it works. Of course it is a java solution.
From: [email protected] [mailto:[email protected]] On Behalf Of eric decoff Sent: Friday, August 21, 2009 4:36 PM To: [email protected] Subject: Re: [AFFUG Discuss] Session timeout Hey Dale, You might want to consider using a timer I put a sample of what I am talking about on my new blog http://ericdecoff.blogspot.com <http://ericdecoff.blogspot.com/> On Fri, Aug 21, 2009 at 1:26 PM, Dale Bronk <[email protected]> wrote: I have looked via debugger and basically expanded every piece of data. I will look at the codes closer though. I gave them a look the first time, but didn't seem to be any different from any other fault. But a second look certainly is not going to hurt. From: [email protected] [mailto:[email protected]] On Behalf Of Marty Blood Sent: Friday, August 21, 2009 1:15 PM To: [email protected] Subject: Re: [AFFUG Discuss] Session timeout 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 <http://www.affug.com/> Archive @ http://www.mail-archive.com/discussion%40affug.com/ List hosted by http://www.fusionlink.com <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 <http://www.affug.com/> Archive @ http://www.mail-archive.com/discussion%40affug.com/ List hosted by http://www.fusionlink.com <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 <http://www.affug.com/> Archive @ http://www.mail-archive.com/discussion%40affug.com/ List hosted by FusionLink <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 -------------------------------------------------------------
