View Single Post
Old 2018-04-02, 06:26   #8
Basketry That Evening!
Dubslow's Avatar
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

11100001101012 Posts

Those both show FF for me in Python.

I'm not sure what precisely is going on. However, I can make an educated guess.

Going back to the number you gave in post 4:

When I click "More information", this number was added approximately 15 hours ago, perhaps 12 hours before you made the post stating that it still appeared as "C". However, the factors are listed as found in early February. So what sort of numbers are these? These seem to be small multiples of other numbers already fully factored in the db?

As for your Python, you said "even after many attempts". How long of a sleep between each request do you use? The FDB is rather notoriously slow about such things, so upon being queried the first time, it often takes several seconds for everything to be fully processed. So if your retry queries have no sleep time between them, and your "many attempts" are all within 1-2 seconds of each other, then that 1-2 seconds is insufficient for the DB to finish processing the new number, and you get C. Then when you check in your browser, at least several if not dozens or hundreds of seconds later, the processing has completed and everything shows normally.

The page I mentioned in passing before, the aliquot sequence status page, queries the status of 100 sequences per half hour, first by querying the known ID of the current line, and then if that has changed to fully factored, using the aliquot sequence page on the FDB to get the latest line, which is itself then processed and stored. Occasionally, when a sequence has had new lines added but no one has queried those new lines, the processing of the newly-added lines gets deferred until someone actually triggers the sequence page on the FDB, and so the blue page's automated query is often the first trigger to actually process all those new lines, meaning that the query about the last unfactored line turns up garbage for several seconds while the newly-added lines are processed. This is analogous to you querying these small-multiples-of-fully-factored numbers for the first time, which turns up a C. In the rare cases that these aliquot sequence queries get garbage, the solution is simple: sleep 5 seconds before trying again. The 5 second sleep is critical to give FDB time to finish processing the stuff that we triggered. After 5 retries, then it quits with an error for that sequence and moves on. Perhaps one sequence out of those hundred-per-half-hour runs into this garbage scenario, on average, and of those, another 99/100 are just fine after up to 25 seconds of querying/sleeping, while ~1 in 10,000 get garbage even after 5 slow retries -- but of those 1 in 10,000, literally none ever cause a problem when queried again in the next half-hourly batch.

So this is what it looks to me is happening. If you can confirm the nature of these numbers that you're querying, and that your "many attempts" are without any sleep between them, and/or change it to be so, that should clear this up.

(As for how I'm querying the FDB -- per the above link, it's just some crappy hand-rolled parsing of the literal HTML webpage. I didn't even know there was an API. I first started this page many years ago, and at the time it occurred to me that there was probably some value in a dedicated Python-FDB interface package, but I never got around to actually doing anything about. In the months-ago rewrite I just slightly cleaned up and reorganized the simple HTTP/HTML handling stuff that had already been in use for years.)
Dubslow is offline   Reply With Quote