NetTalk Central
NetTalk Web Server => Web Server - Ask For Help => Topic started by: AtoB on April 02, 2021, 05:24:15 AM
-
Hi All,
I'm posting this here is I ran into this when working with services in NetTalk. I created a webservice endpoint that needs a GUID for a record-ID and I ran some stress tests on this method. I noticed the backend sometimes gave errors "primary key not unique". Actually restarting the nettalk server several times in a row creates quite a lot of not unique guids.
I've looked at the StringTheory (latest version 3.36) procedure "SeedRandom" (see below) and I think (!) this is maybe where things go wrong. I'm not sure but several things seem strange (but I'm not an expert here ....):
- the "stSeedRandom" calll apparently always takes 0 as an argument (see the self.trace line I added), the clock() and ProcesId seem of no influence ...
- the MouseX/MouseY always return 0 (which maybe is not strange for a nettalk server)
- the seed is "only" determined once (via the static variable), is there a reason for doing this once?
At least the 16 char GUID is not unique enough ...
StringTheory.SeedRandom Procedure()
s1 long,auto
code
stSeedRandom(band(clock(),bshift(stGetCurrentProcessId(),24))) ! process Id's are 16 bit, so we only get the low part of the process ID here
self.trace('mouseex : ' & mousex() & ' stGetCurrentProcessId() : ' & stGetCurrentProcessId() & ' argument :' & band(clock(),bshift(stGetCurrentProcessId(),24)))
loop mousex() TIMES ! take some random calls off the random sequence just to add some more variability
s1 += Chr(Random(1,100))
end
loop mousey() TIMES
s1 += Chr(Random(1,100))
end
-
Looks like an intermittent bug.
He changed the bshift from 16 to 24, which usually creates a negative number in a Clarion LONG and leaves the lower 24 bits zeroes. And then BANDs that with clock(), which returns 0.
Works if the bshift is 16 instead. But even that might have a problem at, say, 20 minutes after midnight when the clock() would still be low enough to BAND to zero.
First screen shot shows a test app that happened to get a process ID of 4484.
24-bit shift results in 75,229,036,544 which overflows a Clarion LONG and leaves a LOT of zeroes to be BANDed (pic from Windows calculator showing result of shift).
Jane
-
The randomness indeed probably is dependant on when the server is actually started.
Out of curiousity:
- this "seed" is the thing that needs to be rather random (as each seed as a "fixed" array of numbers in it)?
- the s1 += chr(random(1,100)) is only to get a more random start in the array?
- effectively this could also be s1 = random(1,100), as the s1 is going nowhere?
-
Fixed in 3.37
thanks
Bruce