@mattab opened this Issue on January 5th 2011 Member

Live! real time widget is somehow reordering visitors before display. This could happen at the JS level, as it seems the returned HTML is in the right order.

I see for example in the returned HTML

  • Wed 5 Jan - 12:33:34 (0s)
  • Wed 5 Jan - 12:33:27 (0s)
  • Wed 5 Jan - 12:33:14 (0s)

But the widget on refresh, fed this HTML, will display

  • Wed 5 Jan - 12:33:14 (0s)
  • Wed 5 Jan - 12:33:27 (0s)
  • Wed 5 Jan - 12:33:34 (0s)

Also it gives the illusion that there are new visits since it refreshes with the visual effect, but in fact there hasn't been any new visitor.

Maybe we should rewrite the Live plugin once and for all to fix existing issues:

  • this issue with random order and wrong refresh
  • 3 http requests but it should only make one
  • do not send more requests when previous ones didn't arrive #1662
  • also I noticed that when the Live! is active and the plugin is shut down, the widget refreshes with bogus data. Instead, if plugin returns error, it should not update the last visitors display and display the returned error at the top of the widget.

The new rewrite could read JSON from the API and write the HTML directly, this would simplify the code.

@halfdan commented on January 5th 2011 Member


@mattab commented on January 5th 2011 Member

Attachment: many requests triggered
many requests.PNG

@halfdan commented on January 5th 2011 Member

I suspect that this is a race condition with slow requests. There is a mechanism to stop ajax request once their result is being parsed, but this does not stop ajax requests being sent when the results hasn't arrived yet (due to slow requests). I prepared a small patch for spy.js - can you check if this fixes the issue? (The issue arrises when two requests return almost at the same time and spy.js is inserting the live visitors item by item)

@mattab commented on January 5th 2011 Member

(In [3624]) Refs #1947 Fixes (?) reordering problem. Kuddos halfdan
Does it also block subsequent http requests until the previous ones have been fetched?

@mattab commented on January 5th 2011 Member

yes it blocks all subsequent http requests, nice!

@mattab commented on January 5th 2011 Member

Sorry I'm spamming, but to answer myself, no it doesn't appear to block all subsequent requests.

To replicate:

  • open Live
  • in Live/API.php add

$i =0;
        while($i<10000000) $i++; }

just after

private function loadLastVisitorInLastXTimeFromDatabase($idSite, $minutes = 0, $days = 0, $type = false )
  • Then let Live! running for few minutes.
  • See screenshot, it started 9 requests at the same time on the server.
@mattab commented on January 5th 2011 Member

(In [3628]) Refs #1947 - displays last page view time instead of first page time

@mattab commented on January 10th 2011 Member

Decreasing priority. We have had this bug for too long, but I have the feeling the final fix will involve rewriting the thing to use Json. If someone is keen or has a patch please comment here

@mattab commented on February 17th 2011 Member

(In [3922]) Fixes #2054, #2076, #1947

  • Visitor Log: offset now removed from Live API all together. As a result, Previous< in the datatable footer will return to the start, this could be improved but OK for now. Offset for next is the ID Visit as before
  • Live! widget: offset is now the timestamp, so the request hits the INDEX
  • This should fix most of the reordering bug: well now it should load on the top, the visits that have been updated since last refresh, and it deletes previous visit rows that are being updated
This Issue was closed on February 17th 2011
Powered by GitHub Issue Mirror