Suitecrm: PHP Session Locking (0 day?)

[Abuelodelanada]

Issue

In a big instance of SugarCRM CE 6.5.18 (But it's the same with SuiteCRM) we had problems with session locking as described in this post: PHP Session Locking

In our case a very long query (for example a custom Dashlet query) made by the CRM in one browser tab, blocks the CRM in other browser tab until the query is resolved.

PHP locks the session until the request is complete or until the session_write_close() method is called.

Expected Behavior

The CRM is not blocked in one browser tab when a long request runs in other tab.

Actual Behavior

The CRM is blocked

Possible Fix

The method startSession() in include/MVC/SugarApplication.php is called in index.php. That method calls start_session().

The problem is that the session remains locked until the request is complete. We should call session_write_close() after setting values in $_SESSION to prevent session locking.
We should not manipulate $_SESSION directly.
May be we should have setter and getter methods that locks and unlocks the session while setting and getting values from $_SESSION.

Steps to Reproduce

1. Write a slow query (Or something that takes a long time to be executed) in the pre_save() method of the controller of a module.
2. Save a bean of that module.
3. That save action will take a lot of time because of the slow query.
4. Open SuiteCRM a new browser tab
5. The new tab will be processed once the query in the pre_save() is resolved

Context

A SugarCRM CE 6.5.18 instance running in 4 nodes, with 200 concurrent users and +2000 unique users in one day

Your Environment

• SuiteCRM Version used: All versions
• Browser name and version: All browsers
• Environment name and version Percona MySQL 5.6 - PHP 5.6 - Apache2.4 - php-fpm
• Operating System and version: Debian 8.

[chris001]

@Abuelodelanada This is 3rd party library is probably the best way to go, it enables using the widely accepted current best practices:
https://github.com/psr7-sessions/storageless

[Abuelodelanada]

@chris001 that's a good (best?) approach. But as SuiteCRM is not using composer yet may be is not a clear solution. Any way, there is more than one possible solution.

[chris001]

@Dillon-Brown I'd label this bug performance. It's definitely not a suggestion. Just because I made a suggestion for a fix to this bug, does not downgrade the seriousness of this bug to a suggestion. Most, like me, agree how it's unacceptable in 2017 on a four-node SuiteCRM system with only 200 concurrent users, to have a human employee wait an excruciatingly long time to do their job, while SuiteCRM's outdated session locking code, written in 2004 on PHP 4.3, is unnecessarily deadlocking another SuiteCRM browser tab.

[Abuelodelanada]

Hi @Dillon-Brown, @samus-aran can you give a look at this issue? I think is a serious problem.
Do you think that my suggestion or the one @chris001 made would be valid?

If so, may be we can write a fix for this.

[micw]

Hello,
we stubled across this issue just a few minutes after the begining of an evaluation: Due to a missconfiguration of the mail server settings, the crm was unable to connect to the email server. This leads to a timeout after a few minutes. The user experience is, that the user/browser who sends the email is not able to use the CRM until the sending times out.

[Abuelodelanada]

Hi @samus-aran can you have a look to this issue?

[Dillon-Brown]

@Abuelodelanada This should be resolved by #7429. Let me know if you encounter any issues. Thanks.

[Abuelodelanada]

Thanks @Dillon-Brown I will check it!

[Abuelodelanada]

Hi @Dillon-Brown

This issue is not resolved with #7429

I did the following:

• Change session.gc.probability in include/SessionHandler to 100 and change session.gc_divisor to 1.

• Set a custom session directory when installing SuiteCRM. (In config.php)

• Check that the new SessionHandler class garbage collection (Which should be running on every page load with the probability change you made) cleans up the sessions.

After that I see the session files are created.

But If I try to reproduce this issue adding a sleep(100); in the __construct of MyCallsDashlet:

The following happens: