Is there any way to disable MediaWiki's limitation of "one active request per browser instance"?
In our MediaWiki site, the #1 source of user confusion (by far) is this limit. When a user encounters a slow wiki page and clicks the browser "Stop" button, the user now cannot view any other wiki pages in that browser window, because the previous request hasn't completed. As a result, the user believes the wiki has crashed and files a support ticket.
Now, the user can simply close and reopen the browser to get a new session cookie, but in practical terms, many end-users don't know this. And even when they DO know it, they believe this behavior is a MediaWiki bug, which breeds distrust of the system, and costs us more time explaining why it isn't a bug.
Why do we have slow-rendering wiki articles? Because some of them, by design, retrieve data from external systems. These retrievals can legitimately take 10 seconds or longer, and they provide VERY high business value so they're not going away. We tried making the requests asynchronous, using AJAX, but this does not avoid the limit.
So, what is the appropriate way to disable the "one request per browser" limitation? We are not worried about individual users abusing the system with multiple requests: this is a private wiki within a corporation.
Thanks, DanB
Daniel Barrett wrote:
Is there any way to disable MediaWiki's limitation of "one active request per browser instance"?
In our MediaWiki site, the #1 source of user confusion (by far) is this limit. When a user encounters a slow wiki page and clicks the browser "Stop" button, the user now cannot view any other wiki pages in that browser window, because the previous request hasn't completed. As a result, the user believes the wiki has crashed and files a support ticket.
Now, the user can simply close and reopen the browser to get a new session cookie, but in practical terms, many end-users don't know this. And even when they DO know it, they believe this behavior is a MediaWiki bug, which breeds distrust of the system, and costs us more time explaining why it isn't a bug.
Why do we have slow-rendering wiki articles? Because some of them, by design, retrieve data from external systems. These retrievals can legitimately take 10 seconds or longer, and they provide VERY high business value so they're not going away. We tried making the requests asynchronous, using AJAX, but this does not avoid the limit.
So, what is the appropriate way to disable the "one request per browser" limitation? We are not worried about individual users abusing the system with multiple requests: this is a private wiki within a corporation.
Thanks, DanB
There's no such limit in MediaWiki.
Sounds more like a server error than a mediawiki error...
Huib Laurens wrote:
Sounds more like a server error than a mediawiki error...
If it is indeed a cookie issue and they can open with two different browsers at the same time, I would suspect of the db or the retrieving extension, not the server itself.
On 10/08/10 03:11, Daniel Barrett wrote:
Is there any way to disable MediaWiki's limitation of "one active request per browser instance"?
In our MediaWiki site, the #1 source of user confusion (by far) is this limit. When a user encounters a slow wiki page and clicks the browser "Stop" button, the user now cannot view any other wiki pages in that browser window, because the previous request hasn't completed. As a result, the user believes the wiki has crashed and files a support ticket.
Now, the user can simply close and reopen the browser to get a new session cookie, but in practical terms, many end-users don't know this. And even when they DO know it, they believe this behavior is a MediaWiki bug, which breeds distrust of the system, and costs us more time explaining why it isn't a bug.
This problem is with the design of PHP's session system. It's not really MediaWiki's fault, although we could fix it by writing our own MySQL-based session system and using it by default.
PHP's file-based session storage locks the session file while the session is open. A concurrent attempt to open the same session by MediaWiki will block until the first request is complete.
You can work around it by installing MemCached and using $wgSessionsInMemcached = true, or by putting the session files on a filesystem that doesn't support locking, such as NFS. Both solutions work by simply removing all locking, so they reintroduce the bugs that the locking in PHP was designed to prevent.
The root problem is that PHP loads the entire session into $_SESSION (in memory), allows the script to modify it, and then stores the whole of $_SESSION back to the file when the session is closed. If any other changes were made to the session data while that script was running, then those changes will be overwritten. A proper solution would have a similar coding style to the DB update code in MediaWiki, with things like transactions and fine-grained locking.
-- Tim Starling
Tim Starling wrote:
PHP's file-based session storage locks the session file while the session is open. A concurrent attempt to open the same session by MediaWiki will block until the first request is complete.
Tim, thanks for your eminently clear explanation of the PHP session behavior. We will investigate the memcached approach.
DanB
mediawiki-l@lists.wikimedia.org