Reset Event Listeners about laravel-swoole HOT 12 CLOSED

Hi @lezhnev74 ,

Not sure what kind of re-initialization logic you need? You can simply reset your instances by setting instances and providers in swoole_http.php config file.

from laravel-swoole.

Hi @aftabnaveed ,

I come up with a solution that can make specific events registered on every request. There's a function in Event Dispatcher called public function forget($event). So you can force some listeners cleared and register them again. But you need to reset the protected $container in event instance, and params injected to newly registered listeners will be correctly resolved with the sandbox app container.

from laravel-swoole.

I bet this is something we need to do upon new request received.
We need some examples of where and how to inject our re-initialization logic (just like this section in an alternative package).

from laravel-swoole.

I am going to try and register my events inside another listener which listens to $this->app['events']->fire('swoole.request'); Let's see what happens.

from laravel-swoole.

Hi @aftabnaveed ,

All the listeners are registered when the application boots up and all the injections are injected based on the original app container, injected request will be empty for sure.

The simplest way to get newest request instance is by app('request') or request(). It's not recommended to reset event instance because all your listeners registered in other places will be lost unless you register them manually.

from laravel-swoole.

Hi @aftabnaveed ,

Is this because you need to get the request and do some log stuff like what you described in #72 ? If yes, the swoole.request will be fired very early before setting the request to newest app container, so what I said above can't resolve your problem.

I will consider to fire a swoole.request event with processed illuminate request to make it easier.

from laravel-swoole.

Is this because you need to get the request and do some log stuff like what you described in #72 ?

@albertcht no I am not its something different that I need for caching. I am basically generating a unique cache identifier for my page based on the request.

I will consider to fire a swoole.request event with processed illuminate request to make it easier.

If you send a processed illuminate request object with swoole.request that would be awesome.

Coming back to the original issue when I checked the Illuminate\Events\EventServiceProvider it registers a singleton, in that case, it makes sense that the listeners are registered only once. I am thinking of a possibility of categorising the events:

1. Global events/listeners which registers during the boot time.
2. Local events which are valid only for request/response lifecycle.

For option 2 I may need to create a separate event instance in the container and then destroy it after the response has returned. What are your thoughts on this?

from laravel-swoole.

Hi @aftabnaveed ,

For option 2 I may need to create a separate event instance in the container and then destroy it after the response has returned. What are your thoughts on this?

I think this is difficult to make it. Is there any reason you need to register the listeners in each request cycle if you can get correct request instance via app('request')?

from laravel-swoole.

I just wanted to keep my code clean, testable and not clutter my listeners by bounding it only to a specific object, in this case, the Request. The other reason is why have something in memory if it's not needed?

from laravel-swoole.

Hi @aftabnaveed ,

I found there's an event which will be triggered Illuminate\Foundation\Http\Events\RequestHandled($request, $response) after dispatching request in Http kernel, so it looks like you can listen to this event directly if you need the request.

from laravel-swoole.

@albertcht it would be nice to have two events fired one which already exists onRequest and the second after a request has been dispatched and swoole is about to return it to the browser. I need the 2nd event to do some cleanup after the request has been dispatched. Is it something you think worth it?

Thank you.

from laravel-swoole.

Hi @aftabnaveed ,

What do you think if you do your cleanup before the request? Does it make any difference in your use case?

from laravel-swoole.