Stack overflow when making a request from within a scheduled call. about http-client

[rdlowrey]

My first instinct is that I don't believe this is an error ... I've encountered this before with xdebug enabled. Try adjusting the following setting or temporarily disabling xdebug:

xdebug.max_nesting_level = 200

That said, it might be an error :) Let me know if this makes it go away and if not I'll look into it further.

[rdlowrey]

Update: I'm getting errors now. Strange. Working on it.

[lt]

I still get it with 200 levels.

In my local copy I have worked around this by moving $callback($watcherId); after reschedule/unset block in doAlarmCallback()

But for all I know there could be a good reason it's done first and I might be breaking something else.

[rdlowrey]

Oh, wait. I realize what the problem is. Your reproduction script is specifying an event reactor that's different from the one used by the AsyncClient underlying the blocking Client.

I have a disclaimer in the docblock but it's probably not enough:

The constructor parameters allow for lazy injection and improved testability. Unless you really know what you're doing you shouldn't specify your own arguments when instantiating Artax\Client objects.

The issue here is that the event reactor must be the same one passed to the AsyncClient. If you change your code to this it will work no problem:

<?php
$reactor = (new \Alert\ReactorFactory)->select();
$asyncClient = new \Artax\AsyncClient($reactor);
$client = new \Artax\Client($reactor, $asyncClient);

The reasoning for this is ...

The blocking Artax\Client class simply wraps the Artax\AsyncClient. For the async client to function it needs an event reactor. But people who want to use the basic client don't want or need to know about what's going on under the hood. The constructor allows you to pass in the dependencies to make testing possible but it doesn't require you to do so.

I could add methods to AsyncClient to start and stop the reactor as needed for the blocking client (to adhere to the Law of Demeter and not reach through it to access the reactor). However I didn't want to complicate the async client's interface with more public methods. Instead I choose to inject the reactor and async clients separately.

The only downside is that until I can find a better way to do this you're forced to inject both. There's probably a better way to handle this but for now just make sure you manually create the async client object with the same event reactor and pass that in as well. In the meantime I can probably add some more error handling and documentationto help others avoid this same pitfall.

[rdlowrey]

Doh. That was part of the problem. But it looks like there's still a memory leak. Back to work.

[lt]

I started by copy/pasting from your examples ;)

Are you sure that's the issue? Checking the constructor, it looks like my supplied reactor is used for the AsyncClient

    function __construct(Reactor $reactor = NULL, AsyncClient $asyncClient = NULL) {
        $this->reactor = $reactor ?: (new ReactorFactory)->select();
        $this->asyncClient = $asyncClient ?: new AsyncClient($this->reactor);

[rdlowrey]

Yeah you're right. My brain is clearly addled this morning. In any case, moving the callback down the method as you suggested solves the problem and all the test cases still pass at 92% coverage so I don't foresee any problems. I'll tag an alert v.0.1.1 shortly with that fix. As always, thanks for the feedback and bug-finding.

[lt]

Ah crap, should have raised the issue on Alert not Artax, I blame submodules!

[rdlowrey]

This issue has been addressed in the Alert dependency (which has been updated). A new version of Artax has been tagged at v0.6.1 incorporating the latest Alert updates.