Closed alexanderdean closed 9 years ago
So are we anticipating that the Tracker will have frequently changing nuid's? Or is this more as a safety net for situations where we have events in the buffer without an nuid and some with and they all get sent with an nuid header?
Have implemented a system whereby if the nuid changes at any point the current buffer will flush and a new buffer will start with the new nuid. This will cover both GET and POST systems in that only the nuid that was set when the event was made will be sent along.
If you imagine a website with 100 concurrent users, and 5 round-robin'ed web servers: the nuid will be constantly changing over time. So I think that your fix will mean that there is effectively no buffering?
/cc @fblundun
Have implemented multiple buffers with multiple NUID's.
We decided on a new approach - instead of sending the network user ID as a header, the tracker should just send it on the querystring with the key "tnuid" (short for "tracker nuid"). So the multiple buffers are no longer necessary.
Sorry for confusion Josh! Fred came up with a much more pragmatic approach. If you could reverse the nuid header and multi-buffer out of the PHP Tracker v0.2.0, that would be most excellent.
All good, it does seem a lot smarter to check it in processing. So now we just pass tnuid as a parameter in either the query string or the POST body.
That's right - just like duid and all the other parameters.
Sounds good! Ill reverse it all now.
Closing as per above thread.
The basic issue is: if you have a batch of 100 events, all with different nuids, in a batch, and that batch is all posted with the same nuid header, then the wrong nuid will be set against almost all of the events.
So if nuid is set for some events, we need to be maintaining a batch per individual nuid. Those batches can safely be POSTed with a common nuid in the header.
Does that make sense? @fblundun can explain more.
This is NFCCWD (Not For Changelog, Close When Done).