#!/usr/bin/perl

use common::sense;
use AnyEvent::HTTP;
use Data::Dumper;

sub do {
    my $iter = shift;

    my $cv = AnyEvent->condvar;
    $cv->begin;
    http_get
        'https://imasheep.hurrdurr.org/category/about.html',
        timeout => 2,
        # out-comment to get the even/odd behavior
        persistent => 0,
        sub {
            my ($body, $hdr) = @_;
            say "$iter $hdr->{Status}";
            unless ($hdr->{Status} == 200) {
                warn Data::Dumper->Dump([$hdr],['hdr']);
            }
            $cv->end;
        }
    ;
    $cv->recv;
}

for (1..4) {
    &do($_);
    sleep(5);
}
[download]

        persistent => $boolean
               Try to create/reuse a persistent connection. When this flag is set (default: true for idempotent
               requests, false for all others), then "http_request" tries to re-use an existing (previously-created)
               persistent connection to the host and, failing that, tries to create a new one.

               Requests failing in certain ways will be automatically retried once, which is dangerous for non-
               idempotent requests, which is why it defaults to off for them. The reason for this is because the bozos
               who designed HTTP/1.1 made it impossible to distinguish between a fatal error and a normal connection
               timeout, so you never know whether there was a problem with your request or not.

               When reusing an existent connection, many parameters (such as TLS context) will be ignored. See the
               "session" parameter for a workaround.

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?

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
---

Yep, this is "ghost-code" from my real project. Forgot to remove it ;)

My sense is that you are comparing apples and oranges here:   a local timer-watcher, which by definition concerns only a single machine (yours), is being weighed against the timeouts of a transaction that is being attempted against a remote.   (There seems to be some specific discussion of this issue in the “Timing Issues” section of the page for AnyEvent.)   I suspect that the “every odd call” phenomenon that you seem to be observing is, in fact, just a fluke.   What you are probably dealing with here is an innocuous expression of what’s called a “race condition.”   The particular results that you deem to be meaningful are probably just the luck of the draw.

What you are probably dealing with here is an innocuous expression of what’s called a “race condition.”

Balooney, its simple granularity, same as with sleep

Not so fast . . . kindly please do not automatically presume that I know not whereof I speak, and thus to dismiss what <<I>&;gt; say on just that reason.   :-)

In the instant case, a local timer, running for so-many milliseconds locally, is being set against a timeout of a remote TCP/IP exchange.   Necessarily, a timeout against a remote machine will require some additional milliseconds to resolve ... milliseconds spent informing the client that a timeout has, in fact, occurred.   The AnyEvent authors were obviously very sensitive to such issues, and they actually spent quite a bit of time in their documentation discussing it.   It appears to me that the OP’s test-case does not take these issues into proper account, thereby leading to the (erroneous?) observation of “even/odd.”

Basically, “it will take you somewhat-more than 200 milliseconds to conclude that a 200-millisecond timeout has timed-out.”   (And, as Anonymous Monk originally observed, it is actually quite unpredictable just how many “more than” milliseconds, might be required.)   A strictly-local timer knows nothing of real-world network delays, whereas a valid conclusion cannot ignore them.   C’est la guerre ...

EDIT:   Kindly now draw your attention to what krambambuli subsequently posted.   I think he hit an important nail on the head here ... and something I did not know ... to decisively explain the “even/odd” behavior.