Databases
StackOverflow2013
Postsdbo
POPHP / AJAX Concurrent Session Misbehaving only in Chrome
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POPHP / AJAX Concurrent Session Misbehaving only in Chrome
    primarykey
    data
    text
    <p>TL;DR. The interesting piece without having to wade through the JS first: I'm incrementing a session counter, yet different requests are seeing the same value. This is only an issue in Chrome. In Firefox and Internet Explorer, every request sees a unique value.</p> <p>I am trying to hit a web page (to process data) a bunch of times until I get a 204 HTTP code. I can do one ajax call at a time, by having the ajax call itself on success, and stopping on 204.</p> <p>Since I want to do them faster, I have multiple "threads" in js all doing that. By that I mean multiple identical ajax calls are created, and they all start another one when they are completed, stopping on the 204 code. </p> <p>My relevant js looks like this:</p> <pre><code>$(function() { // "thread" id var counter = 1; // run 3 "threads" generateThreads(3); function generateThreads(num) { if (num &lt;= 0) return; doNextItem(counter++); // Pause before starting the next thread setTimeout(function() { generateThreads(num-1); }, 50); } function doNextItem(thread) { $.ajax({ url: URL, statusCode: { 200: function(data) { logItem(data, thread); doNextItem(thread); // call itself on the same thread }, 204: function(data) { finished(); // done, don't recurse, end the thread } } }); } }); </code></pre> <p>And then in PHP, I'm incrementing an integer stored in Session and returning 204 when it is over a cutoff.</p> <pre><code>if (!isset($_SESSION["nums"])) { $_SESSION["nums"] = 0; } else if ($_SESSION["nums"] &gt; 10) { http_response_code(204); die(); } echo json_encode(array("num" =&gt; $_SESSION["nums"]++)); </code></pre> <p>And then the weird part comes when I run it. logItem() in the javascript just prints to the console the thread id, then the number from php.</p> <p><strong>Chrome:</strong></p> <pre><code>1: 0 2: 0 2: 1 1: 1 3: 1 2: 2 1: 2 3: 2 1: 3 2: 3 3: 3 3: 4 1: 4 2: 4 3: 5 2: 5 1: 5 2: 6 3: 6 1: 6 1: 7 2: 7 3: 7 1: 8 3: 8 2: 8 1: 9 2: 9 3: 9 2: 10 1: 10 3: 10 </code></pre> <p><strong>Firefox / IE</strong></p> <pre><code>1: 0 2: 1 3: 2 1: 3 2: 4 3: 5 1: 6 2: 7 3: 8 1: 9 2: 10 3: 11 1: 12 2: 13 3: 14 1: 15 2: 16 3: 17 1: 18 2: 19 3: 20 </code></pre> <p>Why is chrome giving me the repeated values?</p> <p><strong>UPDATE</strong></p> <p>Something that is really fishy is that the number of duplicates for each number is exactly equal to the number of ajax calls that are going at the same time. Never less, never more, but exactly. If I run 6 ajax calls at the same time, they all get the same amount. If this was a timing issue, it wouldn't be that consistent, especially because I offset the different ajax calls from each other. This implies to me that it is a javascript issue, not necessarily only a php issue as it appeared before.</p> <p><strong>HUGE GAME CHANGER OF AN UPDATE</strong> This is only an issue in Chrome. Doesn't happen in firefox or Internet Explorer. In Firefox and IE, every request gets a new value of the counter. Clearly this is a client side problem. Doing a little more research with this info brings up a lot of things about invalid requests doing a redirect that kills the session. Specifically a common scenario with the favicon.ico. All of my requests result in a success, and my favicon.ico is successfully loaded as well.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USEli White
    1. USEli White
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POPHP / AJAX Concurrent Session Misbehaving only in Chrome
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POPHP / AJAX Concurrent Session Misbehaving only in Chrome
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POPHP / AJAX Concurrent Session Misbehaving only in Chrome
      1. This table or related slice is empty.
      1. VTUpMod
    1. COAt the time you are sending the session has not yet been set or modified since the end of the previous execution thread will not occur until after all 3 threads are complete. In other words, your just doing the same thing 3 times assyncronously. The variable has not changed. Try a larger interval in your setTimeout()
      singulars
      1. POPHP / AJAX Concurrent Session Misbehaving only in Chrome
      1. USzgr024
    2. COI'm just going to guess you're firing off your ajax calls too quickly. Each one is probably hitting the php page before the server has updated the $_SESSION. Also, javascript is single threaded, so your thread concept seems artificial; presently your 'threads' will never execute concurrently, unless you plan to swap them out with web workers at some point https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers Also, your code example is a strange mixing of concerns: why even have PHP store a value when you could easily track the value in Javascript?
      singulars
      1. POPHP / AJAX Concurrent Session Misbehaving only in Chrome
      1. USMark Fox
    3. CO@zgr024: All the other links on the web state that session_start() locks access to the session file, so no other requests to session with that session id happen concurrently.
      singulars
      1. POPHP / AJAX Concurrent Session Misbehaving only in Chrome
      1. USEli White
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload