http://qs321.pair.com?node_id=1122408


in reply to Re: AnyEvent timers by EV
in thread AnyEvent timers by EV

Ok, if this is "persistent" problem, how AnyEvent->now_update solves it?

And why there is no time-out's at all like in my test-code #2?

Replies are listed 'Best First'.
Re^3: AnyEvent timers by EV
by Krambambuli (Curate) on Apr 04, 2015 at 14:26 UTC
    Most probably ->now_update clears the internal 'cache' entirely, so the persistence is swapped away.

    There is no *timer* timeout because in the example code the timeout is set to 300 seconds - a long time after every action is over. There are however *connection* timeouts - most probably the server closes connections that are idle for seconds, and you are keeping them idle by sleeping 5 seconds between the calls.

    That's what's happening, in sequence:

    1) successful GET; try to keep connection alive
    2) enter sleep
    3) server closes connection
    4) get awake and try a GET; failure. Clear connection cache
    5) sleep
    6) go to 1)

    Krambambuli
    ---
      300 sec timer is unnecessary
      Im intersting only on 2s timer for request
      My guess how it should work is:
      1) try to GET with timeout 2s (timer set to internal time + 2sec, but internal time has lag 5s)
      2) update internal time at ->recv.
      3) fire timeout for GET, because internal time now = real time, and timer+2s is now in the past
      4) throw error about timeout...
      But... maybe before check timeout for connection it already has success status for GET and timeout at this situation is dropped away
        It was me. Sorry, lost login )