AMF Error handling on dead connections

[dropthat50footer]

I apologize if this has been covered here before, but I have looked all over the web and haven't found anything that directly answered my question.

I have written a rather large flash App that uses AMFPHP to interact with a mysql DB.  Everything works great except for one thing.  If the connection to the server that houses gateway.php, or the connection to the DB goes down, a query sent from flash will never return.  Apart from setting a timer in flash and canceling the query that way, is there any way to set it up so an error handler will be called in the event of a dropped connection?  In my current method, after 20 seconds, I consider the connection to be down, but I have no way of actually ensuring that the query cannot still return and call my onResult handler.  I guess I'm just looking for a clean way to handle all error cases including dropped connections.  Anyone have any ideas?

Thanks,

[Ronald Wernecke]

you can start your own timer, which will be terminated by the returning data, or, if elapsed, give a message.

setInterval sets function to be called after e certain time has elapsed - clearInterval cancels it.

For details on parameters, see the help text.

[dropthat50footer]

That's pretty much what I'm doing right now.  The problem with that is, say the timer is set at 20 seconds, but the query returns after 22 seconds.  Then both the onResult code will be run as well as the time out code.  If there was a way to cancel a query once it had been sent, then this would work, but I haven't found a way to do that.  That's why I asking if there was an event from AMF that signaled a connection time out.

[Jorge Solis]

You can just set a flag (say pending = true) in each remoting call, and switch to false on the setInterval call, then on the onResult handler just say

somefunc_onResult(res:Object){
  if(!pending) return
  .....
}

This will ignore the result. Also on a level class such mechanism is easy to implement (and probably I will add to the loading classes http://www.flash-db.com/Tutorials/lclasses/ )

Jorge

[dropthat50footer]

Thanks for the reply.

Actually, again that's exactly what I've done for the time being.  The problem runs a little deeper though.  Sometimes, I need to guarantee that a query hasn't been run before I can re-send it. For example, if I sent an INSERT query to the db, I can't just sit around forever and see if that call returns.  Eventually, I will re-send it, but I'd like to know for sure that the original one failed so that I don't insert that record twice.  I also don't want to have to wait for a slow timer to go off before I can re-send that query.  It'd be much cleaner to handle this in an onConectionFailed handler that AMF returns when it realizes the connection is down.  If it realized it in 1 second, then great, I wouldn't have to sit around for the next 9 and wonder if the query will return.

Anyway, I'm not saying that I can't get around the problem because I have implemented a working solution, it's just not as robust as I would like.  I just wanted to see if there was some sweet way around all this that I was missing.

Thanks.

[Ronald Wernecke]

The problem you are talking about, is - AMF cannot send any response, when the server is down.
You just dont receive anything, because there is nobody answering your request.

If you need to be sure, you have to take care about this issue at the middle tier.

If you want to insert a unique record, you can use a unique key defined at the database. In case you try to insert the same value, you receive an error.

If you cannot handle it this way, you can use a flag in your query, that shows the receiving script, that this is a retry. Then try to read the database first, if you find this record, do not insert, if not, insert.

[Jorge Solis]

That's the problem of asynchronous calls, it could take 1 minute (due to lack on Net conditions) to return a failure message, and your timeout will fire. You should rely on DB tools (index, ids, replace instead of insert) for data integrity

Jorge

[dropthat50footer]

Okay, thanks for the comments - that gives me some better ideas on how to implement what I'm looking for.