Ended the request (and close the session) before core_app_run_after event

[colinmollenhour]

Description (*)

This PR does two things:

1. Explicitly ends the request and closes the session after the app has completed rendering.
2. Adds core_app_run_after event to allow events to occur after response is sent.

With this PR you can add an event observer for core_app_run_after which can do something which will not add any time to the response even if it is long-running (e.g. sleep(3);).

Related Pull Requests

Closes #113

Manual testing scenarios (*)

1. ...
2. ...

Questions or comments

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All automated tests passed successfully (all builds are green)

[fballiano]

the core_app_run_after event won't be able to access any session based data right?

[colinmollenhour]

the core_app_run_after event won't be able to access any session based data right?

I've not tried this.. I think the $_SESSION variable is still present with the same values but I'm guessing that modifying it would simply have no effect.

[luigifab]

Before:

After:

After, __destruct are called after response flushes.

[joshua-bn]

In general, this makes me uneasy. I would offload anything that I wanted to run after to a queue.

[Flyingmana]

the core_app_run_after event won't be able to access any session based data right?

I've not tried this.. I think the $_SESSION variable is still present with the same values but I'm guessing that modifying it would simply have no effect.

its described in this comment here: https://www.php.net/manual/en/function.session-write-close.php#112681

An easy gotcha here - the $_SESSIONS superglobal does not vanish because you call session_write_close. If subsequent to the write_close call if you manipulate the superglobal the changes will not be saved when the script exists. Likewise a call to session_regenrate_id will fail.

So, are we sure there is noone who still access the session after this here was called (in index.php)?

also its probably better to check for the session status instead of the variable https://www.php.net/manual/en/function.session-status.php

[luigifab]

I tested this PR to sync data after each orders.
But to know if the current order is new, I have added:

diff --git a/app/code/core/Mage/Sales/Model/Service/Quote.php b/app/code/core/Mage/Sales/Model/Service/Quote.php
index cf24261eaa..112b74a1f4 100644
--- a/app/code/core/Mage/Sales/Model/Service/Quote.php
+++ b/app/code/core/Mage/Sales/Model/Service/Quote.php
@@ -182,7 +182,8 @@ class Mage_Sales_Model_Service_Quote
 
         Mage::unregister('current_order');
         Mage::register('current_order', $order);
-        
+        $order->setData('new_order', 1);
+
         /**
          * We can use configuration data for declare new order status
          */

Not sure if there is another solution?

---

I also getting a new problem. We are generating our product images with multi threads. With this PR, it continue to work, but, we are waiting all threads to end in a __destruct. Because now __destruct is triggered after response is sent, customers can see blank images when images are not yet generated.

I can fix my problem with a new event before fastcgi_finish_request or by using controller_front_send_response_before event.

[luigifab]

In production for > 4 months.
We must also update EVENTS.md.

The base branch was changed.

[fballiano]

updated EVENTS file

[tmotyl]

shouldn't we use https://www.php.net/manual/en/function.session-status.php here as @Flyingmana suggested?

[fballiano]

#3145